Dan on what domains loader may be understood as by most AIX admins
A common problem on an AIX system, is that a programmer will
rebuild a shared library, and link their program against it, only to
find that their program is still using an old version of the same
library. The problem happens with shared libraries, but doesn't
manifest with statically linked libraries. This scenario is
probably best attributed to a "loader domain problem".
When you compile your program with -L/dir1:/dir2:/dir3, your
program should be built to search in /dir1, /dir2 and /dir3 for your
shared libraries, and the executable should be in the default,
unnamed "loader domain" (more on this in a sec)
When you compile your program with -L/not-a-dir:/dir1:/dir2:/dir3, your
program should still be built to search in /dir1, /dir2 and /dir3 for your
shared libraries, but the executable should be in a loader domain
named "/not-a-dir". This file apparently does not actually have
For each loader domain on an AIX system, there will be a list of
shared libraries, and their versions. Each loader domain can only
have a single version of a given library, but different loader
domains do not have to have the same versions.
Although loader domains look like regular *ix pathnames, they are
apparently just a name for a name space within the AIX kernel -
you could think of them as being indexes to a python "dictionary"
or perl "hash" that exists only inside of the AIX kernel.
The more loader domains you create, the less efficient your
virtual memory (VM) usage is likely to be, because you'll be prone to
ending up with lots of different versions (or identical versions too)
of libraries in your AIX system's VM. However using static
libraries, which is another common workaround for AIX shared
library problems, is likely to waste even more space.
The first time an executable is run in a given loader domain, the
loader domain is created from the perspective of the AIX kernel.
The first time a given library is loaded into a specific loader
domain, that loader domain will hang onto that library's version
until the machine is rebooted, or the library is removed from the
loader domain with slibclean. So if you have a variety of
programs that are all trying to put a mix of different library
versions into the same loader domain, the actual libraries that
end up in that loader domain can be determined by the order in
which the dynamic library versions are first used.
"To dlopen the shared archive, you must set RTLD_MEMBER (or some such)
in the flags, and dlopen the form 'libfoo.a(libfoo.so.1)'."
I've verified that RTLD_MEMBER works.
Kamal R. Prasad on comp.unix.programmer/comp.unix.aix:
The shared library you load for a process contains symbols which are
accessible systemwide. I mean, if another process loads the shared
library -it gets to access the same shared library text (and all its
symbols). In order to allow more than 1 copy of shared text, AIX has a
concept of loader domain.
...you can have as many versions of a given library. For 32-bit, they
are all shared. For 64-bit, it can be privately loaded (and loader
domain becomes irrelevant).
Whether you load mylib.so from /usr/local/lib or /usr/lib is NOT
relevant. What is relevant is that the shared text for mylib.so has
been loaded and will be accessed by any process that may require it in
future. If you have 2 loader domains, you can have 2 versions of
mylib.so (maybe from the same directory bgecause you rebuilt mylib.so)
each in a different domain.
If you are running in 64-bit, it is pretty clean. The libraries of
which you want a personal copy, can be loaded as private modules. The
ones of which you want a systemwide copy can be loaded as shared text.
32-bit address space has its constraints because of which IBM resorted
to all kinds of hacks like maxdata.
Paul Pluzhnikov on comp.unix.programmer/comp.unix.aix:
While AIX shared libraries are indeed a closer match to Win32 DLLs
then to the "normal" ELF shared libraries, there is nothing that
prevents loading multiple copies of libfoo.a(shr.o) if they are
"same-named but different files"; nor loading the same library at
By default, libraries "stick" in memory -- once loaded, you
must reboot the system or perform slibclean(1). This often causes
problems in development -- you rebuild the library but the changes
do not take effect. The "standard" workaround is to remove read
and execute permission for 'other' from the library. Since it
is now not world-readable, the library will be loaded into "private"
memory segment, and will be unloaded as soon as the last process
referencing it terminates.
From Kamal R. Prasad on comp.unix.aix:
dlopen() is an explicit call to do a kind of lazy binding.
The same can be accomplished by
#cc -brtl <files> -l<shared libs>..
What this does is that only when you require a function within a
library, a lookup is done using the procedure link table (plt), and
then the resolved function is called. this way, you can keep updating
shared libraries which programs are running and still expect them to
use the latest functionality.
From the slibclean manual page: The slibclean command unloads all
object files with load and use counts of 0. It can also be used to
remove object files that are no longer used from both the shared
library region and in the shared library and kernel text regions by
removing object files that are no longer required.
Speculation: Can control which loader domain slibclean impacts
Dan on resolving loader domain conflicts:
If you think you can get by with only one version of every library, then
you may be able to slibclean the interfering other versions away.
If you require more than one library by the same name, then you'll
probably either want to recompile the binaries that you require that
need non-AIX libraries that also have AIX versions, specifying a
different loader domain for these programs using -L. Or alternatively,
if you have binary-only applications, or don't want to compile your own
binaries, then you probably want to specify an alternative loader domain
for these programs with the $LIBPATH environment variable.
You -might- end up with a loader domain for every application requiring
a given set of conflicting libraries, rather than just one for non-AIX
libraries, but the latter approach MIGHT be facilitated by writing a
program that loads all of the shared objects for non-AIX libraries that
conflict with AIX libraries, into a common loader domain - assuming you
have sufficient VM available on your system(s) to stack the odds in this
Also, it appears that you can get a peek at a binary's compiled-in
library path with "dump -n /usr/local/bin/ncview". Unfortunately,
this appears to be a human-readable report, more than a
Results of a conversation on Apr 28, 2006 between myself and someone in IBM tech support:
AIX shared libraries have no versioning
More like windows than other *ix's?
ldd-like command available?
Yes, but not until AIX 5.2 ML 4? - my contact seemed not fully certain
What is -brtl?
main application run time linking
shared library run time linking
normally at linked at build time
Differences in 32 bit vs 64 bit behavior?
pretty much the same
two sided archives - 32 64
don't have to stuff a .so into a .a - .so's directly supported
Removing read and execute access to a library?
removing read for other will make library be loaded in private space instead of shared space
libraries they may conflict
can specify a different directory path
Multiple shared objects for a given .a for a given wordsize supported?