This is off-topic, but since there are several helpful and knowledgeable Linux people here, I thought I might ask, as I am in DSO hell.
My application ships and is linked with libgnutls.so.26 and this can be seen with:
$ cd myapp/bin
$ export LD_LIBRARY_PATH=../lib
$ ldd mrViewer | grep libgnutls
libgnutls.so.26 => ../lib/libgnutls.so.26
Now, my application works in all Ubuntu systems and in CentOS 7. However, on RHEL / Rocky Linux 8.6, a user gets the following:
$ cd myapp/bin
$ export LD_LIBRARY_PATH=../lib
$ ldd mrViewer | grep libgnutls
libgnutls.so.26 => ../lib/libgnutls.so.26
libgnutls.so.30 => /lib64/libgnutls.so.30
(0x00007f170833c000)
and when he runs the executable he gets:
mrViewer: symbol lookup error: /opt/mrviewer/mrviewer/lib/libgnutls.so.30: undefined symbol: asn1_der_decoding2, version LIBTASN1_0_3
which is logical as I have an older libtasn1.so.6 in the lib directory of my program that does not contain the symbol asn1_der_decoding2.
However, the puzzle remains... why does ldd list two libgnutls.so
on his system when I never linked against libgnutls.so.30? It
seems some other lib is pulling in libgnutls.so.30 in but not sure
how can I go about finding which one it is.
-- Gonzalo Garramuño ggar...@gmail.com
On Monday, 23 May 2022 at 05:10:35 UTC+1 Gonzalo wrote:
Okay, I found what I needed. lddtree (from app-misc/pax-utils). That
lists DSOs in a tree fashion.
Hi Gonzalo,
Glad you found that - I knew it existed, but couldn't actually remember what it was called!Did it show anything useful?Might be interesting to see what it did show, too.
Yes, it pinpointed the problem. It turns out Red Hat 8 (and later) is linking libgnutls.so.30 into libglib-2.0.so. As I didn't ship my own version of libglib-2.0.so, it would load two libgnutls ( the one I loaded normally and shipped and the one in Red Hat's libglib-2.0.so ). From now on, I will have to ship my own version of libglib-2.0.so.
-- Gonzalo Garramuño ggar...@gmail.com