|Surfing With a Linker Alien
Rod Evans's Weblog
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
% 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,
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
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 :-)
So, blogs seem popular, and a couple of folks have suggested I start one, so here it is. I've been at Sun for 15 years, most of that time developing and maintaining the linker-editors, various related tools, documentation, and building lots of software.
The link-editors start with
I maintain all related manual pages, and the Linker and Libraries Guide. This is one of the few manuals written by the engineers that maintain the code. The DTrace crew have followed this example, and have produced their own excellent documentation.
For those looking for link-editor information, I suggest starting with the latest and greatest, which at this point is a version of the Solaris 10 Linker and Libraries Guide available off of http://docs.sun.com. A good starting point is Appendix A - Link-Editor Quick Reference, a cheat sheet of the various objects that are created by the link-editor. From this section you can vector off to all sort of gory details. If you're not runing Solaris 10 yet (which you could if you used Solaris Express), don't worry. Appendix D - Linker and Libraries Updates and New Features itemizes the major changes from release to release, so you can always determine what is, or isn't available for your release.
But you might be running something newer than you think. The link-editors are delivered as part of the Solaris core OS, however we're always providing new features that are required by other utilities, such as the compliers. And the compilers are delivered asynchronously with various OS releases. Consequently we're always providing patches. And our patches are a snapshot of some of the latest bits available at the time the patch was created. Effectively, we only have one source base for the link-editors. Changes are made in one place, and integrated into the latest patches. Thus a patch to Solaris 8 or Solaris 9, SPARC and Intel, will be the same, and comprise of a snapshot of what's been integrated into Solaris 10. Again, the best place to find documentation is the Solaris 10 Linker and Libraries Guide.
So, that completes this introduction. Hopefully I'll follow up with other postings, perhaps some clarification of existing practice, some new cheat-sheets, or other items that seem helpful. If you've got any comments, questions or advice for improvements, let us know. The door is always open, and we're always looking for ideas and feedback.
Oh yeah, you're supposed to get a little personal with this blog stuff aren't you? When I'm not working, I'm on a bike (road and mountain), or chasing my daughter around. And, having originated from the British Isles, a passion for real beer remains :-)
(2004-07-07 11:49:43.0) Permalink