Re: Linking of libdar64

On 11/07/2023 02:03, John Goerzen wrote:
> Hi Denis,

Hi John,

> 
> One of Debian's automated scan tools detected these warnings:
> 
[...]
> 
> visible at https://buildd.debian.org/status/fetch.php?pkg=dar&arch=amd64&ver=2.7.10-2&stamp=1688852373&raw=0
> 
> Inspecting the library on my system, indeed I see:
> 
> $ ldd /usr/lib/x86_64-linux-gnu/libdar64.so.6000
>          linux-vdso.so.1 (0x00007fff7fbf3000)
>          libargon2.so.1 => /lib/x86_64-linux-gnu/libargon2.so.1 (0x00007f34e3bf9000)
>          librsync.so.2 => /lib/x86_64-linux-gnu/librsync.so.2 (0x00007f34e3beb000)
>          libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f34e3aa5000)
>          liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f34e3a7f000)
>          libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f34e39bf000)
>          liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f34e398e000)
>          liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007f34e3969000)
>          libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f34e3956000)
>          libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f34e3937000)
>          libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f34e392b000)
>          libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f34e36d5000)
>          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f34e34f1000)
>          libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f34e34cd000)
>          libb2.so.1 => /lib/x86_64-linux-gnu/libb2.so.1 (0x00007f34e34ae000)
>          libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f34e3486000)
>          libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f34e33a7000)
>          /lib64/ld-linux-x86-64.so.2 (0x00007f34e3ed6000)
>          libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f34e3354000)
> 
> (no curl there)

ouch...

OK, I have found the problem, it is due to the fact libcurl, libgpgme 
and libthreadar are detected from the configure script (generated from 
configure.ac directives) by relying on the autoconf PKG_CHECK_MODULES 
macro (in order to get the possibly inherited dependent libraries, which 
this is necessary to know for static linking).

This macro creates its own *_LIBS, *_CXXFLAGS *_CPPFLAGS variables and 
those are used at compile time (in Makefiles generated from Makefile.am) 
beside the main LIBS and CXXFLAGS, CPPFLAGS variables (that store the 
libs C++flags and C flags to be added at compilation/linking time, as 
you know).

The side effect I missed seing, is that at building time only the LIBS 
variable seems used by libtool to build the libdar dynamic library... 
linking is fine symbols are found, but the resulting ELF binary has an 
uncomplete header about its dependent dynamic libraries (what ldd lists)
[more precisely searching on Internet, this seems to be the DT_NEEDED 
section of the ELF format, which ldd recursively parse to provide its 
output]

I've fixed that by merging those other *_LIBS/CXXFLAGS/CPPFLAGS into 
their LIBS/CXXFLAGS/CPPFLAGS counterparts... the result seems fixing the 
issue.

If you have the opportunity/possibility to test the 2.7.11.RC1 available 
at https://dar.edrusb.org/dar.linux.free.fr/Interim_releases/ for 
confirmation, I will then release 2.7.11 at next week-end.

> 
> $ grep curl_version /usr/lib/x86_64-linux-gnu/libdar64.so.6000
> grep: /usr/lib/x86_64-linux-gnu/libdar64.so.6000: binary file matches


[...]
> 
> So, I think what this means is that if a third-party package (eg, gdar)
> wants to link with libdar64, it is going to have to know all the correct
> -l libs to add, since there is an incomplete list in libdar itself.

yes, absolutely.

But well, they problem would be hidden because at compilation time (to 
generate static or dynamic executable), gdar or others should know the 
list of library to link with.

I guess gdar relies on pkg-config tool, which libdar has fed at 
installation time with a libdar64.pc file describing the requested 
libraries and cflags:

# pkg-config --libs libdar64 -L/usr/local/lib -ldar64 -largon2 
-lthreadar -lpthread -lgpgme -lassuan -lgpg-error -lcurl -lrsync -lattr 
-lgcrypt -lgpg-error -llz4 -lzstd -llzma -llzo2 -lbz2 -lz -ldl -lcap

#pkg-config --cflags libdar64
-DLIBDAR_MODE=64 -I/usr/local/include

Then at dynamic linking time (when launching gdar), the issue should not 
be present because all libraries should be listed either in libdar's or 
in gdar's ELF header (or both).

But anyway, this Debian tool is good and pertinent!

Thanks for feedback!

> 
> The fix, I believe, would be to list all the relevant libs when building
> libdar.

should be the case now, let me know about 2.7.11.RC1 if you can

> 
> Thanks,
> 
> John
> 

Cheers,
Denis