This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking against shared objects that reside at different paths on link-time versus runtime?


On 21 June 2011 17:42, Dun Peal wrote:
> On Tue, Jun 21, 2011 at 11:29 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 21 June 2011 17:24, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> Rename it to libbar.so and link to it with "-L/foo -lbar" instead of
>>> giving an absolute path to the .so
>>
>> Actually I think I've misremembered how it works, you might need to
>> create bar.so using -soname=bar.so so that ldd will only make it
>> depend on "bar.so" not the absolute path to the file, and will search
>> for it in the usual locations.
>
> Thanks, unfortunately `bar.so` is a closed-source binary, and `-L/foo
> -lbar` fails.

That's because -lbar tells the linker to look for libbar.so or
libbar.a, it won't find bar.so

> Is there a way to know which `-soname` `bar.so` was assigned? ?Maybe

on GNU/Linux:
readelf -d bar.so | fgrep SONAME

on Solaris use elfdump instead of readelf, there should be similar
commands on other OSs

I assume that won't return anything, if bar.so had a soname it would
be used by ld instead of creating a dependency on the file's absolute
path.

> it's just different from `bar`, and if I just `-l<actual bar.so name>`
> I'd be OK?

That's not how it works.  -lbar tells the linker to look for
libbar.so, and if it finds libbar.so with a soname it creates a
dependency on the soname, if it finds libbar.so without a soname it
creates a dependency on the file's name, including the full path when
you link to /foo/bar.so.  So -lxxx can only match a file called
libxxx.so (or libxxx.a), to do what you suggest it would have to open
every single file and check if it has the requested soname, that won't
work.

>>> Use an RPATH, e.g. link with -Wl,-rpath,'/baz:$ORIGIN/..' will make it
>>> look in /baz then in ..
>
> Thanks, but I take your answer to mean that I can't link relative to a
> runtime target's environment variable (e.g. `$HOME`)?

Correct, use LD_LIBRARY_PATH at runtime to do that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]