unbundled shared libraries
2007-12-25 7:32:00
------------------------------------------------------------------------
I am at a loss as to how to manage the dynamic shared libraries and
directories that come with Sun's unbundled compilers. At load time, the
compiler commands (eg f77) know where its libraries are, and adds the list
of directories to be search when invoking the ld command, e.g.:
f77 -v -o mmdtsun mmdtsun.o
results in:
/bin/ld -dc -dp -e start -u _MAIN_ -X -o mmdtsun /usr/lang/SC1.0.1/crt0.o
/usr/lang/SC1.0.1/cg87/_crt1.o -L/usr/lang/SC1.0.1/cg87 -L/usr/lang/SC1.0.1
mmdtsun.o -lF77 -lm -lc
The list of additional library directories:
-L/usr/lang/SC1.0.1/cg87 -L/usr/lang/SC1.0.1
is placed in the executable and used by the dynamic loader at runtime to
find the required libraries that are used to resolve dynamic references.
This would work fine if newer versions of the libraries were added to the
same directory to either replace or supplement the older libraries.
However, f77 has used the following directories for different versions:
f77 1.3.1: /usr/lang/SC0.0
f77 1.4 /usr/lang/SC1.0
f77 1.4 Patch 1: /usr/lang/SC1.0.1
When I removed the older library directory (/usr/lang/SC0.0) due to a space
crunch, users started get the following messages when I running old
executables:
ld.so: libF77.so.1: not found
I can think of a number of ways to solve this problem, each having a
drawback.
1. Keep all old libraries around.
With /usr/lang/SCx.y taking up roughly 10 MB, this seems impractical for
many versions.
2. Have users add /usr/lang/SCx.y to their LD_LIBRARY_PATH environment
variable in their .cshrc or .login file. This means that when I as system
administrator install a new compiler or library directory I need to inform
all my users to update their .cshrc/.login and .profile files.
3. Have users' .cshrc or .login file source a system-wide file that sets up
then LD_LIBRARY_PATH environment variable (as well as other
installation-dependent stuff). I use this approach, but this does not solve
the problem for program invoked from cron, which uses sh to invoke the
programs. I guess I could do the same thing for user's .profile files.
4. Remove the old /usr/lang/SCx.y directories and make create symbolic links
by the same name to the newest usr/lang/SCx.y directory. Are there any
unforseen problems with this approach? I realize that if the major version
number of the new library changes I need to either keep the old one or have
users recompile/relink their programs, but higher minor version numbers
should be OK.
------------------------------------------------------------------------
Responses:
I got 4 responses. They primarily refer to the system-wide use of the
ldconfig command to cache (and thereby find) auxilliary shared libraries.
1. From: keves@meaddata.com (Brian Keves - Consultant)
I have always used option #2 in the past.
2. From: chuck-strickland@orl.mmc.com
One other option I use: In /etc/rc.local you will find a command ldconfig
near the end. You can add more libraries to the search path for the loader
on this command. It works well for me. You only have to update the rc.local
on all of your machines each time you add a library. We have a standard
rc.local for all of our machines and use rdist to keep it updated.
3. From: pvo@oce.orst.edu (Paul O'Neill)
from my rc.local:
if [ -f /usr/etc/ldconfig ]; then
ldconfig; echo "link-editor directory cache"
if [ -d /usr/lang/SC0.0 -a -d /usr/local/lib ]; then
ldconfig /usr/lang/SC0.0 /usr/local/lib
fi
fi
4. From: dank@blacks.jpl.nasa.gov (Dan Kegel)
Are you aware that sunos has a bug in ld that prevents all but the first
member of LD_LIBRARY_PATH from being obeyed? They have a patched version of
ld, which is available from sun or from my machine (blacks.jpl.nasa.gov) in
directory pub.
----------------------------------------------------------------
Doug Neuhauser Seismographic Station
doug@perry.berkeley.edu ESB 475, UC Berkeley
Phone: 415-642-0931 Berkeley, CA 94720
Comments
Got something to say?
You must be logged in to post a comment.
