Index | Thread | Search

From:
Marc Espie <marc.espie.openbsd@gmail.com>
Subject:
Re: pkg_create: @lib without LIBname_VERSION
To:
George Koehler <kernigh@gmail.com>, ports@openbsd.org
Date:
Sat, 8 Nov 2025 17:48:22 +0100

Download raw body.

Thread
On Sat, Nov 08, 2025 at 08:32:46AM -0800, Andrew Hewus Fresh wrote:
> On Sat, Nov 08, 2025 at 11:00:39AM +0100, Marc Espie wrote:
> > On Fri, Nov 07, 2025 at 10:52:05PM -0500, George Koehler wrote:
> > > pkg_create has some code to check every @lib in a PLIST is correctly
> > > versioned (by expanding ${LIBname_VERSION}).  This check is broken, so
> > > the error never happens.  The broken code will cause a warning in
> > > Perl 5.42, so we must change it before we update Perl.
> > > 
> > > When I fixed the check, it broke a few ports,
> > > 
> > > $ make -C lang/vala print-plist-all >/dev/null                        
> > > Error: Incorrectly versioned shared library: \
> > > @lib lib/libvala-${API_V}.so.${LIBvala-${API_V}_VERSION}
> > > 
> > > This @lib line is correct, but pkg_create looked for the exact string
> > > '${LIBvala-0.56_VERSION}' in the unsubstituted line, and didn't find
> > > it, because API_V=0.56 was unsubst.  There are more than 30 ports like
> > > this; see list below diff.  (Because print-plist-all can produce the
> > > error, I didn't need a bulk build to find the broken ports.)
> > > 
> > > I want to commit this version of the diff, which has '0 &&' to disable
> > > the check, so ports like lang/vala don't break.  The other changes in
> > > this diff are,
> > >  - Change "!$x =~ m/y/" to "$x !~ m/y/", which fixes the Perl 5.42
> > >    warning "Possible precendence problem between ! and =~".
> > >  - Add \Q and \E to the regexp, so libestdc++ stops matching
> > >    '${LIBestdcccccc_VERSION}'.
> > >  - Pass the unsubstituted string to check_version: the caller did
> > >    "my $s = $subst->do($l);", so pass $l, not $s.
> > > 
> > > In the future, we might modify and enable this check.  For example, we
> > > might compare libvala's filename's version with LIBvala-0.56_VERSION,
> > > without looking for '${LIBvala-0.56_VERSION}'.  This might work for
> > > devel/libtalloc,-python which has,
> > > 
> > > @lib lib/libpytalloc-util.${PYTALLOC_UTIL_LIBSUFFIX}
> > > 
> > > We can't enable a check now, because cad/qcad has lines like,
> > > 
> > > @lib share/qcad/plugins/script/libqtscript_core.so.1.0
> > > 
> > > There is no LIBqtscript_core_VERSION=1.0; and I'm not sure whether to
> > > add these plugins to SHARED_LIBS or change them from @lib to @so.
> > > 
> > > Is this diff with '0 &&' ok?
> > > --gkoehler
> > 
> > No.
> > 
> > Andrew has had a patch to fix the warning for ages by now.
> 
> I did, which was the obvious first part of this patch (without `0 &&`),
> but sadly had to revert it:
> 
> https://github.com/openbsd/src/commit/192820d0400a512050d40845c284e95be601625e
> 
> I didn't have the other part (pass in $l not $s), and gkoehler figured
> it out before I had time to dig into it.  (Many thanks for that!)
> 
> > And the ports that do not have proper lib version naming should be fixed
> > anyway.
> 
> Probably true, I totally would not have expected `.` to be valid in 
> '${LIBvala-0.56_VERSION}', but it testing shows it is.
> 
> That doesn't solve the problem that it doesn't say `0.56` but instead
> `${API_V}` or the special cases with libtalloc,python or qcad.

I'll have a look, but basically, perl doesn't have to look into that,
it's more a question of getting the right stuff into the Makefile
proper.

Namely, SHARED_LIBS doesn't have to be purely constant, it can reuse
other libs. The only drawback would be that you may have to edit it manually.

To be more specific about controlling shared libs versions: we've been
burnt once. Not having full control is a problem each time we make compiler
ABI range (last big one was changing size_t in C++).

Getting in front of that, namely making sure we can bump all libraries version,
is something I lost enough hours on to not want to ever go back.

The fact the check was broken and allowed a few rogue libs to sneak by is
no reason to go back.

If you wonder whether it should be @so's with no version at all or @lib 
libraries, that's a secondary concern, imo. Make sure everything
that says "@lib" has a corresponding SHARED_LIBS, then you can
decide what you want to do.

No exceptions.


-- 
	Marc