Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/QNX Momentics Community Support/How do I tell which version of a shared object .so the linker used?/List of Posts
Forum Topic - How do I tell which version of a shared object .so the linker used?: (4 Items)
   
Update
Kevin Schaffer(deleted)
02/12/2015 5:22 PM
post113307
How do I tell which version of a shared object .so the linker used?   
I have an executable that's generating an error at runtime:

lddFATAL Could not load library libicui18n.so.49

This is because the linker is linking it to point to the libsqlite3.so that comes with QNX 6.6.  However, we have our 
own self-contained libsqlite3.so we've been using for just such a reason.

How can I tell which .so the linker chooses to dynamic-link against.  This can either be at linktime or later with, say,
 the objdump utility.

Note:  "our" libsqlite3.so is built and is in the link path (in fact, it is the very first option on the link line, -
L(path to our libsqlite3.so directory) when we get around to linking the executable, which is the very last thing we do.
  There is no build/link of the libsqlite3.so after that; it occurs much earlier.

We also use this in the link command:

 -Wl,-Bdynamic -lsqlite3

So why is it going into the QNX libraries before going into our -L(custom path)?
Ryan Mansfield(deleted)
02/12/2015 5:37 PM
post113308
Re: How do I tell which version of a shared object .so the linker used?   
Readelf -d or objdump -x will ‎list the soname of the shared object linked against.

If at link time, you can specify the  -Wl,-t option to trace the shared objects linked a‎gainst.

Regards,

Ryan Mansfield
  Original Message
From: Kevin Schaffer
Sent: Thursday, February 12, 2015 5:22 PM
To: momentics-community
Reply To: momentics-community@community.qnx.com
Subject: How do I tell which version of a shared object .so the linker used?


I have an executable that's generating an error at runtime:

lddFATAL Could not load library libicui18n.so.49

This is because the linker is linking it to point to the libsqlite3.so that comes with QNX 6.6.  However, we have our 
own self-contained libsqlite3.so we've been using for just such a reason.

How can I tell which .so the linker chooses to dynamic-link against.  This can either be at linktime or later with, say,
 the objdump utility.

Note:  "our" libsqlite3.so is built and is in the link path (in fact, it is the very first option on the link line, -
L(path to our libsqlite3.so directory) when we get around to linking the executable, which is the very last thing we do.
  There is no build/link of the libsqlite3.so after that; it occurs much earlier.

We also use this in the link command:

 -Wl,-Bdynamic -lsqlite3

So why is it going into the QNX libraries before going into our -L(custom path)?




_______________________________________________

QNX Momentics Community Support
http://community.qnx.com/sf/go/post113307
To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com
Max Feil
02/18/2015 5:08 AM
post113324
RE: How do I tell which version of a shared object .so the linker used?   
It sounds like your LD_LIBRARY_PATH is not set correctly at runtime. To trace exactly where shared libs are being picked
 up from at runtime, set environment variable DL_DEBUG to "libs", for example:

# DL_DEBUG=libs sqlite3

Max

P.S. You can use the -rpath linker option at build time to override LD_LIBRARY_PATH, but that can make things confusing 
later. I use "objdump -p" to see the rpath info in an executable or shared object.

-----Original Message-----
From: Ryan Mansfield [mailto:community-noreply@qnx.com] 
Sent: Thursday, February 12, 2015 5:37 PM
To: Kevin Schaffer; momentics-community
Subject: Re: How do I tell which version of a shared object .so the linker used?

Readelf -d or objdump -x will ‎list the soname of the shared object linked against.

If at link time, you can specify the  -Wl,-t option to trace the shared objects linked a‎gainst.

Regards,

Ryan Mansfield
  Original Message
From: Kevin Schaffer
Sent: Thursday, February 12, 2015 5:22 PM
To: momentics-community
Reply To: momentics-community@community.qnx.com
Subject: How do I tell which version of a shared object .so the linker used?


I have an executable that's generating an error at runtime:

lddFATAL Could not load library libicui18n.so.49

This is because the linker is linking it to point to the libsqlite3.so that comes with QNX 6.6.  However, we have our 
own self-contained libsqlite3.so we've been using for just such a reason.

How can I tell which .so the linker chooses to dynamic-link against.  This can either be at linktime or later with, say,
 the objdump utility.

Note:  "our" libsqlite3.so is built and is in the link path (in fact, it is the very first option on the link line, -
L(path to our libsqlite3.so directory) when we get around to linking the executable, which is the very last thing we do.
  There is no build/link of the libsqlite3.so after that; it occurs much earlier.

We also use this in the link command:

 -Wl,-Bdynamic -lsqlite3

So why is it going into the QNX libraries before going into our -L(custom path)?




_______________________________________________

QNX Momentics Community Support
http://community.qnx.com/sf/go/post113307
To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com




_______________________________________________

QNX Momentics Community Support
http://community.qnx.com/sf/go/post113308
To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com
Kevin Schaffer(deleted)
02/18/2015 10:36 AM
post113325
Re: RE: How do I tell which version of a shared object .so the linker used?   
Ok, I figured out what was happening.

I was (I am pretty sure) linking correctly against the self-contained sqlite3 .so we build (I assume??? the linker "
checks out" that one of the listed .so actually contains the functions the main executable will want to use.)

But on the target device, the old QNX-supplied sqlite3.so was installed, so when runtime rolled around, the main 
executable tried to use that one, which failed because further dependent .so down the line were not on the device.

I'm still a little hazy on what the linker does to verify the .so contains what's needed by the main executable being 
linked, but it looks like something like that.  And at runtime, it has the other .so, crosses its fingers, and makes a 
go of it, choking gracefully.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems