This section is a tad short right now; it will be expanded over time as I gut the ELF howto
Linux has shared libraries, as you will by now be sick of hearing if you read the whole of the last section at a sitting. Some of the matching-names-to-places work which was traditionally done at link time must be deferred to load time.
Send me your link errors! I won't do anything about them, but I might write them up ...
can't load library: /lib/libxxx.so, Incompatible version
(a.out only) This means that you don't have the correct major version of the xxx library. No, you can't just make a symlink to another version that you do have; if you are lucky this will cause your program to segfault. Get the new version. A similar situation with ELF will result in a message like
ftp: can't load library 'libreadline.so.2'
warning using incompatible library version xxx
(a.out only) You have an older minor version of the library than the person who compiled the program used. The program will still run. Probably. An upgrade wouldn't hurt, though.
There are a range of environment variables that the dynamic loader
will respond to. Most of these are more use to ldd
than they are
to the average user, and can most conveniently be set by running ldd
with various switches. They include
LD_BIND_NOW
--- normally, functions are not `looked up' in
libraries until they are called. Setting this flag causes all the
lookups to happen when the library is loaded, giving a slower startup
time. It's useful when you want to test a program to make sure that
everything is linked.
LD_PRELOAD
can be set to a file containing `overriding'
function definitions. For example, if you were testing memory
allocation strategies, and wanted to replace `malloc', you could write
your replacement routine, compile it into malloc.o
and then
$ LD_PRELOAD=malloc.o; export LD_PRELOAD
$ some_test_program
LD_ELF_PRELOAD
and LD_AOUT_PRELOAD
are similar, but only
apply to the appropriate type of binary. If
LD_
something_PRELOAD
and LD_PRELOAD
are set, the
more specific one is used.
LD_LIBRARY_PATH
is a colon-separated list of directories
in which to look for shared libraries. It does not affect ld; it
only has effect at runtime. Also, it is disabled for programs that
run setuid or setgid. Again, LD_ELF_LIBRARY_PATH
and
LD_AOUT_LIBRARY_PATH
can also be used to direct the search
differently for different flavours of binary. LD_LIBRARY_PATH
shouldn't be necessary in normal operation; add the directories to
/etc/ld.so.conf/
and rerun ldconfig instead.
LD_NOWARN
applies to a.out only. When set (e.g. with
LD_NOWARN=true; export LD_NOWARN
) it stops the loader from
issuing non-fatal warnings (such as minor version incompatibility
messages).
LD_WARN
applies to ELF only. When set, it turns the
usually fatal ``Can't find library'' messages into warnings. It's not
much use in normal operation, but important for ldd.
LD_TRACE_LOADED_OBJECTS
applies to ELF only, and causes
programs to think they're being run under ldd
:
$ LD_TRACE_LOADED_OBJECTS=true /usr/bin/lynx
libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
libc.so.5 => /lib/libc.so.5.2.18
This is very close to the way that Solaris 2.x dynamic loading
support works, if you're familiar with that. It is covered
extensively in H J Lu's ELF programming document, and the
dlopen(3)
manual page, which can be found in the ld.so
package. Here's a nice simple example though: link it with
-ldl
#include <dlfcn.h>
#include <stdio.h>
main()
{
void *libc;
void (*printf_call)();
if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
{
printf_call=dlsym(libc,"printf");
(*printf_call)("hello, world\n");
}
}