-L and shared libraries

-L and shared libraries

[Thomas Lavergne]

Hi all,

    I bumped into an issue this afternoon (european time) with gcc and the linking of dynamic 
libraries. It is not the first time I run into it but this time I will try to get an answer from you 
gurus. I browsed the archive for this list and the closest I could get was a message in 2003, 
looking like:

************************
 > We want to set up gcc to search /usr/local/GCC/lib when compiling
 > *without* having to set up LD_LIBRARY_PATH.  Is there a way of doing
 > this?

  -Ldir Add directory dir to the list of directories to be searched for
        `-l'.
*************************
I do not fully agree with the answer. It seems to me that -Ldir answers to only part of the problem 
(on my Linux-x86 configutation, at least).

I hope confirmation or pointing to section of the man pages :-)

My situation is,
 > gcc bar.o -o bar.exe -lfoo
does work because foo.so is in the default search path (/usr/lib/libfoo.so exists).

But I want to use the version of foo which is in /usr/local/GCC/lib. So I use:

gcc -L/usr/local/GCC/lib bar.o -o bar.exe -lfoo

This also compiles smoothly. I note that it would also compile ok if there was no libfoo.so in the 
/usr/local/GCC/lib. There would also be no further problem if both versions of libfoo was static 
objects.

*But*, coming back to my .so case, if I try
 > ldd bar.exe
I see that the reference to foo.so is in /usr/lib. :-o.
I have to 1) either set the LD_RUN_PATH but it is too tedious as I have several other libraries and 
I am lazy or 2) use:

 > gcc -L/usr/local/GCC/lib bar.o -Wl,-rpath=/usr/local/GCC/lib -o bar.exe -lfoo
Then ldd gives ok result.

So now my questions:
1) what controls this behaviour (that the dynamic loader still tries to load foo.so from the default 
directories)? Is it a feature of gnu ld? Is it different on other architecture?
2) should not the semantic of -L be exactly that? If you are to link against a dynamic library, pass 
-rpath=libdir to the linker.
3) could we imagine a new flag (-LLdir) that would automatically pass the -rpath=dir info to ld (of 
course only if libfoo is a dynamic libary)? That would be a cool feature, wouldn't it?


Et voila.
Sorry if it is FAQ or solved elsewhere. I definitely wait for some enlightments...
Thomas

PS: Please answer to me as I am not subscribed to the list.

RE: -L and shared libraries

[John (Eljay) Love-Jensen]

Hi Thomas,

>1) what controls this behaviour (that the dynamic loader still tries to load foo.so from the default directories)?

If the information is not baked into the appliaton with -rpath, then the user's runtime LD_LIBRARY_PATH controls the location foo.so is loaded from.

> Is it a feature of gnu ld?

-rpath is supported by ld on some platforms (such as Linux and Solaris).

-rpath and LD_LIBRARY_PATH are features of ld.so and ld-linux.so.

> Is it different on other architecture?

Yes.  For example, Windows uses PATH (with a few other caveats for first-look locations), and OS X's dyld uses DYLD_LIBRARY_PATH (and a few others) and has a utility called install_name_tool to bake preferred locations into an executable.

I wouldn't be surprised to find out that HP-UX, AIX, DEC VMS, and DEC Tru64 have different mechanism.

Mac OS 9 (and earlier) also have different mechanism.

Amiga OS also has a different mechanism.

> 2) should not the semantic of -L be exactly that?

No.  That would break almost all currently compiling-and-running executables.

> If you are to link against a dynamic library, pass -rpath=libdir to the linker.

Then that makes an assumption about other machines that may run your executable that may not be correct.

If you are only concerned about applications built on your machine, that only going to run on your machine... then sure.  And that's what the -rpath mechanism does.  (-rpath can be used for either absolute paths, or relative paths (with the security concerns that relative paths imply.)

Microsoft's Linux-targeted applications gets around the problem by making a bootstrap shell script which specifies the LD_LIBRARY_PATH of the application explicitly.  And since that shell script is constructed during installation time, it can accommodate any target location instead of having a requirement that it be installed at a particular location due to baking in the path information into the executable.

> 3) could we imagine a new flag (-LLdir) that would automatically pass the -rpath=dir info to ld (of course only if libfoo is a dynamic libary)? That would be a cool feature, wouldn't it?

Not appropriate for all platforms.

And on the platforms it is appropriate, the -rpath machanism already exists and has been used for many years.

HTH,
--Eljay

Re: -L and shared libraries

[Thomas Lavergne]

John (Eljay) Love-Jensen wrote:
> And on the platforms it is appropriate, the -rpath machanism already exists and has been used for many years.
> 
> HTH,
> --Eljay
Dear Eljay, list,
    Thank you for this answer. It both confirms my "findings" and shows me how small a picture I 
had, as usual.  I will now be more aware and start using -Wl,-rpath more frequently for software 
that is build at my machine and that runs on my machine only.
All the best,
Thomas