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.


> There is a reason we want to take control of shared libs version and the
> fact that this check got broken is no reason to disable it.

Seems reasonable, how do we fix the examples to be able to do that?

-- 
andrew

The 3 great virtues of a programmer: Laziness, Impatience, and Hubris.
                      --Larry Wall