OT: shared libs conflict

[Gonzalo Garramuño]

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

[Gonzalo Garramuño]

On 22/5/22 17:18, Basile Starynkevitch wrote:
>
> Maybe ldconfig should be run. Or unset LD_LIBRARY_PATH.
>
LD_LIBRARY_PATH is set to the location of my application DSOs. In the
example case, ../lib (but I use the full path on a startup script).

Not sure what ldconfig would accomplish.


> Use also the strace(1) or ltrace(1) utilities.
>
strace is helpful in that it shows all DSOs being loaded. However, it
does not seem to list them in a tree view fashion (or in a proper order
either), which is what I would need.   I am looking for the equivalent
of Windows' DLLs Dependency Walker (depends.exe).


> BTW, I am seeking partners interested by http://refpersys.org/
>
Cool.  Unfortunately, I have no clue about artificial intelligence, so I
wouldn't know where to begin.

[Gonzalo Garramuño]

On 22/5/22 21:08, Gonzalo Garramuño wrote:
> strace is helpful in that it shows all DSOs being loaded. However, it
> does not seem to list them in a tree view fashion (or in a proper
> order either), which is what I would need.   I am looking for the
> equivalent of Windows' DLLs Dependency Walker (depends.exe).

Okay, I found what I needed. lddtree (from app-misc/pax-utils). That
lists DSOs in a tree fashion.

[Ian MacArthur]

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.

As an aside - I'm not really understanding what you are doing - it sounds to me like you are linking a number of SO files into your app, and providing them in a private libs folder, specific to your app? (To which end you are overwriting LD_LIBRARY_PATH to find your "local" libs.)

Would it not be cleaner to simply static link the "local" libs and then allow the default library load path to load all the other "system" libs that are needed?

As I say, I'm not at all clear on what you are doing, so I was puzzled...

As an aside, I'm not all that comfortable with the possibility that your app might be loading two different versions of the TLS lib here, that just seems... scary, frankly.

I think I'd be more comfortable if there was only one!

 

[Gonzalo Garramuño]

El 23/5/22 a las 05:31, Ian MacArthur escribió:

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.

Hi, Ian,

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