added some info to mail/aix

diff --git a/mail/aix b/mail/aix
new file mode 100644 (file)
index 0000000..7f6b2d3
--- /dev/null
+++ b/mail/aix
@@ -0,0 +1,118 @@
+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 ---