[knc1]

Pathnames:

There are two pathname tags of interest in runtime dynamic loading.
There is also an (un-documented) maximum string length limit.
Which was the death of the V-0.2 series of builds.

Two tags, four cases:
0) Neither (the default linker output)
1) DT_RPATH (only)
2) DT_RUNPATH (only)
3) Both

For case #3 (Both), the DT_RPATH tag is ignored and the DT_RUNPATH is used (I.E: Collapses into a case #2).

Case 1: DT_RPATH (only)
Provides the path(s) to be searched for the NEEDED soname libraries.
This path is used in all searches, it is not restricted to the imports of the ELF file it appears in.

This tag **DOES** over-ride LD_LIBRARY_PATH environment settings.

Case 2: DT_RUNPATH (only or both)
Provides the path(s) to be searched for the NEEDED soname libraries.
This path is used ONLY for searching for the imports of the ELF file it appears in. I.E: Its scope is the current file requesting the import of other soname libraries.

This tag **DOES NOT** over-ride LD_LIBRARY_PATH environment settings.

All cases (including Case 0):
Unless over-ridden, the loader will search the system directories: /lib and /usr/lib.
(Which is useless for this thread, those are all soft-float libraries that we can not link with.)

Filenames:

Linux (and all *nix systems) follow a library naming convention that includes the ABI and library version in the visible filename.
Details: http://tldp.org/HOWTO/Program-Librar...libraries.html

The internal (DT_SONAME) of the library is the load-time, actual, name of the library.

For instance:

Dynamic section at offset 0xaf04 contains 23 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libbsd.so.0]

I.E:

Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with ``lib'').

So this file contains the [lib] bsd [.so] [.0] code, regardless of its external name on the file system.
And the (symbol) imports should be found in the file with the internal (soname) [lib] c [.so] [.6] code, regardless of its external name on the file system.

In the above case, the name of this file on the file system is:

core2quad lib $ ls -l libbsd.so.0.3.0
-rw-r--r-- 1 root root 46744 2011-06-04 01:19 libbsd.so.0.3.0

Which has the major [.3] and minor [.0] version numbers appended to the soname.

On file systems which support symbolic links, the soname appears on the file system as a symbolic link to the fully versioned binary.

core2quad lib $ ls -l libbsd.so.0*
lrwxrwxrwx 1 root root    15 2012-06-07 22:06 libbsd.so.0 -> libbsd.so.0.3.0
-rw-r--r-- 1 root root 46744 2011-06-04 01:19 libbsd.so.0.3.0

Since FAT32 does not support dynamic links, we have two choices:
* Rename the fully versioned binary to the soname (what I did in version-0.1 to the libc library)
or
* Leave the binary with its fully versioned name and just let the loader search for it.

(or
Get the loader to use a cache file in a non-standard location.
That could be done, but might not be worth the effort to maintain.
This is a slow e-book not a high-performance machine.
)

- - - - -

Unrelated to dynamic loading, there is another naming convention used by the build-time linker.

From the -lbsd option passed to the compiler/linker -
The "-l" specifies a name mangling that adds the 'lib' prefix and the '.so' dynamic library extension.

The build-time linker then searchs for: libbsd.so for the code to link.
On Linux (and other *nix) development systems, this name will also be a symbolic link to the fully versioned filename of the library binary.

But FAT32 does not do symbolic links.
Does that mean we can't do program development on FAT32 - No
(Although it certainly isn't recommended, it can be done. )

Creating a file named: libbsd.so
with the contents:

INPUT(libbsd.so.0.3.0)

(or to the file named the same as the soname, if we choose to rename the fully versioned binary)

Will keep the build-time linker happy.

Edit:
Could I patch ld.so to follow the same convention?
Interesting thought (and it might already do it, will have to read the source).