Linking of libdar64

Hi Denis,

One of Debian's automated scan tools detected these warnings:

dpkg-shlibdeps: warning: symbol curl_version used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gpgme_signers_add used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol _ZN11libthreadar9condition4waitEj used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gpgme_new used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol curl_version_info used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol _ZN11libthreadar6threadD2Ev used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gpgme_op_encrypt_sign used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gpgme_get_protocol_name used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol curl_easy_setopt used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gpgme_data_new_from_cbs used by debian/libdar64-6000/usr/lib/x86_64-linux-gnu/libdar64.so.6000.6.0 found in none of the libraries
dpkg-shlibdeps: warning: 41 other similar warnings have been skipped
(use -v to see them all)

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)

$ 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

The build line for the .so includes, in part:

.libs/limitint.o .libs/parallel_tronconneuse.o
.libs/parallel_block_compressor.o   -largon2 -lpthread -lrsync -lgcrypt
-lgpg-error -llz4 -lzstd -llzma -llzo2 -lbz2 -lz -ldl -lcap
-L/usr/lib/gcc/x86_64-linux-gnu/12
-L/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/12/../../.. -lstdc++
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/12/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crtn.o  -g
-O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now
-Wl,-soname -Wl,libdar64.so.6000 -o .libs/libdar64.so.6000.6.0

No -lcurl there either.

Now dar itself includes -lcurl in the build:

/bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2 -ffile-prefix-map=/home/jgoerzen/work/dar=. -fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -Wl,-z,now -o dar command_line.o config_file.o dar.o dar_suite.o hide_file.o no_comment.o line_tools.o crit_action_cmd_line.o ../libdar/libdar64.la -lcurl  -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lthreadar -lpthread   -largon2 -lpthread -lrsync -lgcrypt -lgpg-error -llz4 -lzstd -llzma -llzo2 -lbz2 -lz -ldl -lcap

So we're not having dynamic loader errors from dar, because -lcurl is
linked into the binary.  The python binding is doing the same:

g++ -shared -Wl,--no-as-needed -L/usr/lib/x86_64-linux-gnu -lgpgme -lcurl  -lthreadar -lpthread  ../libdar/.libs/libdar64.so pybind11_libdar.o  -o libdar.cpython-311-x86_64-linux-gnu.so

And indeed:

$ ldd /usr/lib/python3/dist-packages/libdar.cpython-311-x86_64-linux-gnu.so | grep curl
        libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007feec54ba000)

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.

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

Thanks,

John