From: Alexandre Oliva Date: Wed, 13 Jan 1999 13:04:47 +0000 (+0000) Subject: added some info to mail/aix X-Git-Tag: automake_1-4~42 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=47ff66f5e02f27b985e2e52ddff23cc4388b0aa8;p=thirdparty%2Flibtool.git added some info to mail/aix --- diff --git a/mail/aix b/mail/aix new file mode 100644 index 000000000..7f6b2d32d --- /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 +Resent-To: bug-libtool@gnu.org +Date: Sun, 10 Jan 1999 14:28:11 +0300 (MEST) +From: Andrey Slepuhin +Organization: Moscow State University Network (MSUnet) +To: Alexandre Oliva , Thomas Tanner , + "Gary V.Vaughan" + +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 -l" and as "/". In the + first case is added to global search path, where all + libraries will be searched on program startup. In the latter case + 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: 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 ---