• 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 to exist.
• 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.

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.

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 different addresses.

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.

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 using $LIBPATH?

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 way.

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 machine-readable report.

• AIX shared libraries have no versioning
• More like windows than other *ix's?
  • yes
• 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?
  • yes
• Document about AIX linking and loading
  • http://www.ibm.com/developerworks/eserver/pdfs/aix_ll.pdf

You can e-mail the author with questions or comments: