Stefan Varga <Stefan_Varga@xxxxxxxxxx> asks on Mon, 28 Nov 2005 15:26:36 +0100 about preventing this sort of error: $ ldd libz.so libgcc_s.so.1 => (file not found) I have always felt that it is a design flaw in the Unix loader that it does not record in the output executable file the location of a shared library that it found successfully at link time. The solution is to specify a loader option that requests such recording. Depending on the compiler, this is usually an option of one of these forms: -Wl,-rpath,$(prefix)/lib gcc, g++, FreeBSD, SGI, Sun compilers -rpath $(prefix)/lib Compaq/DEC, SGI compilers -Rdir:dir:dir Portland Group, Sun compilers Notice that SGI and Sun support two such flavors. IBM AIX 4.x compilers seem to record this information automatically, and, in fact, don't even use .so files for shared libraries: they use the .a versions directly, and don't even offer the user a choice between dynamic and static linking. Compaq/DEC OSF/1 ld automatically includes /usr/local/lib in the search path. Thus, when I build software on a GNU/Linux systems, I often have something like this: env CC=/usr/bin/cc \ CXX=/usr/bin/c++ \ LDFLAGS="-Wl,-rpath,/usr/local/lib" \ ./configure && make all check Because I often build software in over 100 compilation environments, I hide this mess in configuration files for the build-all system: http://www.math.utah.edu/pub/build-all/ The alternatives are all unpleasant: (1) require all users to define LD_LIBRARY_PATH in their shell environments to include $(prefix)/lib; (2) wrap the executable in a shell script that sets LD_LIBRARY_PATH, so that users do not have to; (3) add $(prefix)/lib to the run-time loader search path. For (3), on GNU/Linux, this means adding a directory to /etc/ld.so.conf, then running /etc/ldconfig each time that directory is updated with new libraries, and doing so on every machine in your environment that shares the same $(prefix) file tree. There is an analogous system for Sun Solaris, but we never use it, precisely because it requires updates on every machine (in my case, 100+). Another problem that we have run into is conflicts on some GNU/Linux systems, notably with Gnome tools, between shared libraries in /usr/lib vs $(prefix)/lib, so we have moved away from touching /etc/ld.so.conf. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@xxxxxxxxxxxxx - - 155 S 1400 E RM 233 beebe@xxxxxxx beebe@xxxxxxxxxxxx - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - -------------------------------------------------------------------------------
