+++ /dev/null
-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 ---
projects / thirdparty / libtool.git / commitdiff
