mirror/libtool
2
0
Fork 0
mirror of git://git.savannah.gnu.org/libtool.git synced 2024-11-21 01:40:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

mail/aix has been resolved

Browse Source
This commit is contained in:
Alexandre Oliva 1999-01-20 13:16:21 +00:00 committed by Gary V. Vaughan
parent c50684a06e
commit 19c4321c19
1 changed files with 0 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
mail/aix
View File

@ -1,118 +0,0 @@
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 ---