Re: libmd.so.6 and pkgbase

On 07/10/24 14:49, Mark Millard wrote:
> Renato Botelho <garga_at_FreeBSD.org> wrote on
> Date: Mon, 07 Oct 2024 14:20:00 UTC :
> 
>> On 07/10/24 03:53, Baptiste Daroussin wrote:
>>> Hello everyone,
>>>
>>> Just a reminder when using pkgbase, make sure you do activate
>>> BACKUP_LIBRARIES=true in pkg.conf
>>>
>>> This way pkg will save a copy of libmd.so.6 during the upgrade in
>>> /usr/local/lib/pkg/libmd.so.6 (and create a package named compat-libraries to
>>> track it).
>>>
>>> This will prevent you from having a couple of days without a new version of pkg
>>> built against libmd.so.7 available (or some of the packages which also requires
>>> libmd.so.7.
>>
>> I have BACKUP_LIBRARIES=true on my pkg.conf and upgraded a system
>> running CURRENT this morning using pkgbase. After that I got pkg linked
>> with both libmd.so.6 and libmd.so.7:
>>
>> root@x230:~ # ldd /usr/local/sbin/pkg
>> /usr/local/sbin/pkg:
>> libelf.so.2 => /lib/libelf.so.2 (0x28b8027a6000)
>> libjail.so.1 => /lib/libjail.so.1 (0x28b80340b000)
>> libssl.so.30 => /usr/lib/libssl.so.30 (0x28b80436a000)
>> libcrypto.so.30 => /lib/libcrypto.so.30 (0x28b804e18000)
>> libarchive.so.7 => /usr/lib/libarchive.so.7 (0x28b805e0a000)
>> libbz2.so.4 => /usr/lib/libbz2.so.4 (0x28b80710e000)
>> libz.so.6 => /lib/libz.so.6 (0x28b807ccc000)
>> liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28b808368000)
>> libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5
>> (0x28b806205000)
>> libm.so.5 => /lib/libm.so.5 (0x28b808952000)
>> libutil.so.9 => /lib/libutil.so.9 (0x28b808ad1000)
>> libmd.so.6 => not found (0)
>> libthr.so.3 => /lib/libthr.so.3 (0x28b809f4c000)
>> libc.so.7 => /lib/libc.so.7 (0x28b80ae53000)
>> libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x28b80c034000)
>> libmd.so.7 => /lib/libmd.so.7 (0x28b80cdf7000)
>> libsys.so.7 => /lib/libsys.so.7 (0x28b80ddb1000)
>> [vdso] (0x28b801eee000)
> . . .
> 
> It would help for tracking down were the dependencies are
> to use "ldd -a ". It shows what each involved *.so.*
> in turn references of itself. The example below is for
> a context that does not have the problem you report
> (not a pkgbase context) but it illustrates the type of
> extra information that is output:
> 
> # ldd -a /usr/local/sbin/pkg
> /usr/local/sbin/pkg:
> 	libelf.so.2 => /lib/libelf.so.2 (0xc4840f00000)
> 	libjail.so.1 => /lib/libjail.so.1 (0xc48410d3000)
> 	libssl.so.30 => /usr/lib/libssl.so.30 (0xc4841fae000)
> 	libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
> 	libarchive.so.7 => /usr/lib/libarchive.so.7 (0xc4843af6000)
> 	libbz2.so.4 => /usr/lib/libbz2.so.4 (0xc48403f6000)
> 	libz.so.6 => /lib/libz.so.6 (0xc4845351000)
> 	liblzma.so.5 => /usr/lib/liblzma.so.5 (0xc48455b0000)
> 	libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0xc484480f000)
> 	libm.so.5 => /lib/libm.so.5 (0xc48463e4000)
> 	libutil.so.9 => /lib/libutil.so.9 (0xc4846b3d000)
> 	libmd.so.7 => /lib/libmd.so.7 (0xc48477f3000)
> 	libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libelf.so.2:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libjail.so.1:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /usr/lib/libssl.so.30:
> 	libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libcrypto.so.30:
> 	libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /usr/lib/libarchive.so.7:
> 	libz.so.6 => /lib/libz.so.6 (0xc4845351000)
> 	libbz2.so.4 => /usr/lib/libbz2.so.4 (0xc48403f6000)
> 	liblzma.so.5 => /usr/lib/liblzma.so.5 (0xc48455b0000)
> 	libbsdxml.so.4 => /lib/libbsdxml.so.4 (0xc4849553000)
> 	libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0xc484480f000)
> 	libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /usr/lib/libbz2.so.4:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libz.so.6:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /usr/lib/liblzma.so.5:
> 	libmd.so.7 => /lib/libmd.so.7 (0xc48477f3000)
> 	libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /usr/lib/libprivatezstd.so.5:
> 	libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libm.so.5:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libutil.so.9:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libmd.so.7:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> /lib/libthr.so.3:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> 	libsys.so.7 => /lib/libsys.so.7 (0xc484af47000)
> /lib/libc.so.7:
> 	libsys.so.7 => /lib/libsys.so.7 (0xc484af47000)
> /lib/libbsdxml.so.4:
> 	libc.so.7 => /lib/libc.so.7 (0xc484889d000)
> [preloaded]
> 	[vdso] (0xc483f927000)
> 
> 
> I expect that /usr/local/sbin/pkg has the only reference
> to libmd.so.6 in your context and that /usr/lib/liblzma.so.5
> is what is referencing libmd.so.7 .
> 
> If so, I'll note that you can avoid the problem by using
> pkg-static instead of pkg as your command:
> 
> # ldd -a /usr/local/sbin/pkg-static
> ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
> 
> So there is no use of *.so.* files for pkg-static .
> 
> (I make no claims about other programs that might be involved
> overall.)

I've fixed it by building pkg on local ports tree.  But anyway I've 
forced a bootstrap to have the one provided by official repository 
installed again and ran ldd -a to collect data

root@x230:~ # ldd -a /usr/local/sbin/pkg
/usr/local/sbin/pkg:
	libelf.so.2 => /lib/libelf.so.2 (0x1a55a0de2000)
	libjail.so.1 => /lib/libjail.so.1 (0x1a55a1fae000)
	libssl.so.30 => /usr/lib/libssl.so.30 (0x1a55a1fc2000)
	libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
	libarchive.so.7 => /usr/lib/libarchive.so.7 (0x1a55a3e98000)
	libbz2.so.4 => /usr/lib/libbz2.so.4 (0x1a55a4a17000)
	libz.so.6 => /lib/libz.so.6 (0x1a55a4d85000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x1a55a57ed000)
	libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x1a55a640f000)
	libm.so.5 => /lib/libm.so.5 (0x1a55a696c000)
	libutil.so.9 => /lib/libutil.so.9 (0x1a55a6e12000)
	libmd.so.6 => not found (0)
	libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libelf.so.2:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libjail.so.1:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libssl.so.30:
	libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libcrypto.so.30:
	libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libarchive.so.7:
	libz.so.6 => /lib/libz.so.6 (0x1a55a4d85000)
	libbz2.so.4 => /usr/lib/libbz2.so.4 (0x1a55a4a17000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x1a55a57ed000)
	libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x1a55a834a000)
	libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x1a55a640f000)
	libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libbz2.so.4:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libz.so.6:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/liblzma.so.5:
	libmd.so.7 => /lib/libmd.so.7 (0x1a55a853a000)
	libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libprivatezstd.so.5:
	libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libm.so.5:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libutil.so.9:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libthr.so.3:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
	libsys.so.7 => /lib/libsys.so.7 (0x1a55a8908000)
/lib/libc.so.7:
	libsys.so.7 => /lib/libsys.so.7 (0x1a55a8908000)
/lib/libbsdxml.so.4:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libmd.so.7:
	libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
[preloaded]
	[vdso] (0x1a559fe96000)

It seems pkg is still linked with libmd.so.6 and lzma is linked with 
libmd.so.7.  Anyway we have a problem, keeping libmd.so.6 seems not to 
be enough to have pkg working
-- 
Renato Botelho