From: Marc Espie Subject: Re: pkg_create: @lib without LIBname_VERSION To: George Koehler Cc: ports@openbsd.org, andrew@afresh1.com Date: Sat, 8 Nov 2025 11:00:39 +0100 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. And the ports that do not have proper lib version naming should be fixed anyway. 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.