[M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc.

[Jay]

http://linuxmafia.com/faq/Admin/ld-lib-path.html




Why setting LD_LIBRARY_PATH is considered harmful
For the following reasons: 

LD_LIBRARY_PATH is used in preference to any run time or default system linker path. If (God forbid) you had it set to something like /dcs/spod/baduser/lib, if there was a hacked version of libc in that directory (for example) your account could be compromised. It is for this reason that set-uid programs completely ignore LD_LIBRARY_PATH. 
When code is compiled and depends on this to work, it can cause confusion where different versions of a library are installed in different directories, for example there is a libtiff in /usr/openwin/lib and /usr/local/lib. In this case, the former library is an older one used by some programs that come with Solaris. 
Sometimes when using precompiled binaries they may have been built with 3rd party libraries in specific locations; ideally code should either ship with the libraries and install into a certain location or link the code as a pre-installation step. Solaris 7 introduces $ORIGIN which allows for a relative library location to be specified at run time (see the Solaris Linker and Libraries Guide). The alternative is to set LD_LIBRARY_PATH on a per-program basis, either as a wrapper program to the real program or a shell alias. Note however, that LD_LIBRARY_PATH may be inherited by programs called by the wrapped one ... 


http://lists.trolltech.com/qt4-preview-feedback/2005-04/msg00648.html

 

Requiring LD_LIBRARY_PATH is not a good idea imo. It's a variable meant to
override defaults, not for the common case. If all packages on ours disks
would require this variable hell would break loose. Ask a system
administrator.


.... different person...

 

 

Unfortunately rpath is not a solution by itself (although it could be 
part of the solution). Having rpath point to the build directory is a 
security hole. It can be part of the solution though

 

 

..yet another...shades of things I have said here...

 

Now you may argue that runMyAppUsingQtAndMyLib needs to be re-linked 
deployment anyway. I agree that's what some programs do or should do 
(some have even suggested to distribute *.o files and relink them on the 
target platform using an adequate rpath, but that's a bad idea since the 
linker may be unpatched and the C++ compiler broken on the target 
platform). Some users won't relink though. Shouldn't Qt protect them by 
default?

What do you think?


 

http://lists.apple.com/archives/Unix-porting/2005/May/msg00034.html


 

As others have pointed out there is not really an equivalent of LD_LIBRARY_PATH because the whole shared library system is unique to MacOS X/Darwin.

I think it is fair to say that if you find yourself using DYLD_LIBRARY_PATH except for testing uninstalled binaries, then you are doing it wrong. Every executable file on Darwin contains the full paths of the libraries against which it was linked, and these are used first by dyld at runtime. They can be changed after linking. (see docs about install_name) So you should never need to specify some odd DYLD_LIBRARY_PATH with a properly installed library wherever it is installed.


 

So now maybe I should search the web for negative comments about $origin?

Well, when I try "what is wrong with ld $origin" I again find criticism of LD_LIBRARY_PATH. :)

Ok, I admit I didn't look very hard. I'll look more later.

 

So you see, the point is, there is a lot stuff out there discouraging LD_LIBRARY_PATH and encouraging full paths and/or $origin. Including Sun's linker developer(s).

Full paths are ok for us, to the symlinks, if we then have full paths within the files.

But if we use $origin, then the pkg store bites us.

 

 

Is some of this making sense?

 

 - Jay


 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Thu, 2 Jul 2009 18:56:27 +0000
Subject: Re: [M3devel] ROOT, $ORIGIN, runpath, LD_LIBRARY_PATH, symlinks, hardlinks, etc.



Here are some good links, other people trying to explain this stuff:
 
 
http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the
 
Avoiding LD_LIBRARY_PATH: The Options
With the introduction of the elfedit utility into Solaris, we have a new answer to the age old question of how to avoid everyones favorite way to get into trouble, the LD_LIBRARY_PATH environment variable. This seems like an appropriate time to revisit this topic. 
LD_LIBRARY_PATH Seems Useful. What's the Problem?
 
 
http://blogs.sun.com/rie/entry/hello_there
 
 
Surfing With a Linker Alien 
 

http://blogs.sun.com/rie/entry/tt_ld_library_path_tt
 
LD_LIBRARY_PATH - just say no 
A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries. But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker for an overview of LD_LIBRARY_PATH use at runtime. 
People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running: 
    % ldd -s /usr/bin/date
    ...
    find object=libc.so.1; required by /usr/bin/date
 search path=/opt/ISV/lib  (LD_LIBRARY_PATH)
If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance. 
Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals: 
    LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\
 $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"`
The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories. 
When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting. 
 
Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute. Sigh. 
Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded. If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname. 
 
Is there a limitation to $ORIGIN use? Yes, as directed by the security folks, expansion of this token is not allowed for secure applications. But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway. See Security. 
For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-) 
(2004-07-10 22:20:54.0) Permalink Comments [8] 
Comments:

....
 
 
 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090702/bb0ad19b/attachment-0002.html>