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: -L and shared libraries


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


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