ELF is a binary format designed to support dynamic objects and shared libraries. On older COFF and ECOFF systems, dynamic support and shared libraries were not naturally supported by the underlying format, leading to dynamic implementations that were at times complex, quirky, and slow.

You probably left off the --export-dynamic option when linking the application. This is required only if arbitrary symbols in the program might be needed by the dynamically loaded module, for example, if a program intends to make run-time decisions to dynamically load modules it was never linked with. Note, when running cc(1) instead of ld(1) this will be specified as -Wl,--export-dynamic.

Ideally, there is no need for ldconfig or for /etc/ld.so.conf, since ELF provides good and predictable (read portable) mechanism to locate shared libraries. Unfortunately there are still a few corner cases (like wanting to run setuid binaries that you dont have the source for, that want shared libraries to be installed somewhere you dont like). For those corner cases, youll find that creating an /etc/ld.so.conf file, will still work. Read on though about other ways of doing this and why it is not a good idea. The next section discusses the ELF mechanisms for locating shared libraries.

An ELF program needs to know the directory and the filename required to mmap(2) its shared libraries. Encoded within the file name is version information. There are one set of mechanisms for the directories and a different mechanism for the file names.

Although rarely used, the optional LD_LIBRARY_PATH environment variable specifies a colon-separated search path. This can be used in wrapper scripts as needed for misconfigured applications. It is ignored for setuid binaries.

The primary directory locating mechanism is the ``rpath search list contained within the executable image. This search list is set with the -R directive to ld(1). The POSIX syntax for passing ld(1) options through the compiler front end is:

For example: -Wl,-R/usr/something/lib. Multiple -R directives can be given to a single application to create a shared library search path.

This directive is also known as -rpath. Using -R has the advantage of working in older versions of NetBSD as well.

When shared libraries are created, the -soname directive is used to record the major version number of the library in the internal DT_SONAME field. The actual library is installed as, for example,

The idea is that Makefiles will want to link against only the plain .so file. (Who would want to go around changing all the Makefiles just because a new library version was installed?) Once linked, however, the program does want to be aware of the major version but does not want to deal with the minor version.

Consequently, the library itself knows that it is libgizmo.so.4 because a -soname libgizmo.so.4 directive was used when it was created. The program knows it got major version 4 because the linker copied the libgizmo.so.4 DT_SONAME string out of the library and saved it in the executable.

You dont say -soname libgizmo.so, because then the program would use the latest major number and would break if that ever changed. (The major number only changes if the new library is incompatible.) You dont say -soname libgizmo.so.4.2, because then the installation of a compatible change that bumps the minor number would unnecessarily break the linked images.

To compile f.c and make an installable shared library out of it:

At first glance, it might seem reasonable, why shouldnt people be able to move things around to anywhere they want and correct the consequent lossage in a /etc file?

In fact, some developers of ELF systems have apparently added such a file, but with mixed results. The ELF mechanism was designed to correct some of the previous problems, and introducing the old mechanism would bring many of those old problems back.

Currently we are even supporting the /etc/ld.so.conf functionality in our ELF linker, but it is not at all clear that a hybrid mechanism is the right solution. For that reason we do not advertise its existence, advocate its use, or even provide a default installation template. It is there for those who think that they really need it, and cannot live without it.

The recommended method is to install a ELF snapshot. If you try upgrading via source and something goes wrong it is very easy to hose your system such that it will not even boot to single-user mode.

However for those who wish to upgrade from source: (this should work on i386, sparc and any platform that uses ld.new and gas.new)

If you are running an ELF system your compiler will define the constant __ELF__.