libtool/mail/aix

Subject: Some notes about shared libraries on AIX 4.x
Resent-Date: 13 Jan 1999 04:26:06 -0200
Resent-From: Alexandre Oliva <oliva@dcc.unicamp.br>
Resent-To: bug-libtool@gnu.org
Date: Sun, 10 Jan 1999 14:28:11 +0300 (MEST)
From: Andrey Slepuhin <pooh@msu.ru>
Organization: Moscow State University Network (MSUnet)
To: Alexandre Oliva <oliva@dcc.unicamp.br>, Thomas Tanner <tanner@gmx.de>,
     "Gary V.Vaughan" <garyv@oranda.demon.co.uk>

Hi libtool maintainers,
Here is a copy of my letter to Gordon Matzigkeit on 29-Sep-98.
Unfortunately, I didn't receive any responce (as I understand
because Gordon leaved libtool development). I'm glad to see
a progress on libtool, so I resent this message to you in hope
that it can help a little. This message contains only some notes,
but really I have working libtool on my system and almost no
problems with packages installation. The reason not to send
a patch is because a) I have changed gcc specs and b) I do not
understand clearly libtool policy with shared libraries
dependencies. Please feel free to request any info if you need.

Best regards,
Andrey.

P.S. Do you plan to setup libtool mailng list?

--- Begin of resent message ---
Hi Gordon,
I spent much time fighting against libtool and shared libraries
support on AIX. My system is powerpc-ibm-aix4.2.1.0, but I also
know issues relating to AIX4.1.x. So, here are some notes.

I. AIX4.1.x systems.

1) AIX4.1.x doesn't support unresolved symbols in shared libraries.
   More precisely, you can create such library passing -berok option
   to linker, but these undefined symbols will not be resolved later
   due to the lack of run-time linker. Unfortunately, most packages
   which use libtool do not pass dependent libs to it. This forces
   such packages to use static libraries, while really it is
   possible to use shared ones. So I think libtool should claim
   to pass *all* dependent libraries to it, and it should decide
   itself whether to use dependent libraries or not.

2) Shared objects on AIX can be linked both directly and as members
   of archives. Currently libtool encapsulates shared object into
   an archive. This is not good, because such shared libraries cannot
   be used via dlopen(). It is better to create one more symbolic link.
   Or may be it is even better to pass a special option to libtool if
   a target library will be used via dlopen().

3) Static and shared libraries use the same namespace, yes. I suggest
   to use a name "${libname}-ar.a" for static libraries; such solution,
   for example, is used when building libstdc++. Unfortunately, libtool
   doesn't allow to tune a name of static library.

II. AIX4.2 and later.

1) AIX4.2 and later *does* support unresolved symbols in shared libraries
   and run-time linking. You only need to pass -G flag to linker when
   you create a shared object and you also should pass -brtl option to
   linker when you create an executable. I did this on my system by
   tuning gcc specs. But there are still some subtle problems with
   dependent libraries, discovered when building glib. We have
   libgmodule which depends on libdl, but -ldl is not passed to linker
   when libgmodule is created, so libgmodule contains dlopen, etc.
   symbols undefined. Later, testgmodule executable is created using
   -lgmodule -ldl. But testgmodule doesn't depend on libdl itself, so
   obtained executable doesn't include libdl in its header as dependent
   library. As a result, run-time linker cannot resolve dl* symbols.

2) AIX4.2 and later *does* support both *.so and *.a as library names,
   if -bdynamic option is passed to linker.

III. Some notes on hardcoding library paths.

1) On AIX there is a big difference between passing library to linker
   as "-L<somepath> -l<somelib>" and as "<somepath>/<somelib>". In the
   first case <somepath> is added to global search path, where all
   libraries will be searched on program startup. In the latter case
   <somepath> will be tightly attached to the specific library and
   this library *never* will be searched somewhere else. On AIX4.2 and
   later this behavior can be changed using -bnoipath option.

2) It is possible to exactly tell to the linker the path where you
   want to search for shared libraries. This can be done using
   -blibpath:<libpath> option. All directories specified via -L flag
   and in LIBPATH will be ignored. Default directories /lib and /usr/lib
   will be ignored too, so you should add them to the path pointed via
   -blibpath option.

IV. AIX and versioning support.
   AIX linker doesn't support versioning. But in principle, it is
   possible to have an archive with multiple versions of the same
   shared object. All versions except latest should be marked via
   F_LOADONLY flag in XCOFF header. This pevents linker from using
   old versions of shared object when building new applications,
   but allows existing applications to load and run. Unfortunately,
   I don't know how to manage F_LOADONLY flag using standard system
   tools. I also don't know if this feature has enough functionality
   for full versioning support.

V. Gcc and automatic shared libraries creation.
   On my system I'm using egcs-1.1, which has reworked collect2
   with direct support of shared libraries creation. I.e. you
   can only specify -shared gcc option. So the tricks with nm
   are not necessary in this case. Moreover, now collect2 on AIX
   supports automatic creation of C++ shared libraries in a
   single linker pass. Unfortunately I don't know if this feature
   was merged into gcc development tree.

Hope these notes can help you in further libtool development.
Feel free to ask me any questions.

Regards,
Andrey.
--- End of resent message ---