Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
On 11/25/2014 02:53 PM, David Edelsohn wrote: Now that things have calmed down with respect to breakage on AIX, the patch for building libgcc_s is okay. FYI: libtool-2.4.4 does support --with-aix-soname=aix|both|svr4 now too, http://thread.gmane.org/gmane.comp.gnu.libtool.patches/11789/focus=11802 Is there a libtool upgrade planned for gcc-5 as well? Thanks! /haubi/
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
On Fri, Dec 5, 2014 at 7:56 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: On 11/25/2014 02:53 PM, David Edelsohn wrote: Now that things have calmed down with respect to breakage on AIX, the patch for building libgcc_s is okay. FYI: libtool-2.4.4 does support --with-aix-soname=aix|both|svr4 now too, http://thread.gmane.org/gmane.comp.gnu.libtool.patches/11789/focus=11802 Is there a libtool upgrade planned for gcc-5 as well? Patches are backported as needed. - David
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
On Tue, Nov 11, 2014 at 10:42 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: On 11/11/2014 04:02 PM, David Edelsohn wrote: Michael, Why does the configure change match with p*-*-aix... instead of power* or powerpc*? Yes, it's unique and will match, but why make it as short as possible, which doesn't match other uses? Actually I did have powerpc* initially, but gmp-6.0.0 config.guess'ed power7-ibm-aix6.1.0.0 now. Then I've thought that one may use ppc as well, but now I see this config.sub's to powerpc anyway, so power* is fine. Patch updated. In your documentation, how are you distinguishing between Dynamic Linking and Runtime Linking? I've tried to use the same naming scheme as in the ld Command Reference and the dlopen Subroutine man pages. Actually, there is at linktime: Dynamic Linking: also known as Dynamic Mode or (more common) Shared Linking: record a shared object's name into the created binary at runtime: Runtime Loading: load these shared objects at process startup Runtime Linking: resolve the symbols after loading shared objects Dynamic Loading: load shared objects by application logic with dlopen() I'm unsure how to make this as clear as possible though. Now that things have calmed down with respect to breakage on AIX, the patch for building libgcc_s is okay. Thanks, David
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
Michael, Why does the configure change match with p*-*-aix... instead of power* or powerpc*? Yes, it's unique and will match, but why make it as short as possible, which doesn't match other uses? In your documentation, how are you distinguishing between Dynamic Linking and Runtime Linking? Thanks, David On Mon, Nov 10, 2014 at 12:41 PM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-10 17:06, schrieb David Edelsohn: On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-07 20:52, schrieb David Edelsohn: First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches. I don't have a fundamental objection to including this option, but note that Richi, Honza and I have discovered that using AIX runtime linking option interacts badly with some GCC optimizations and can result in applications that hang in a loop. Feels like adding the aix-soname linking procedure becomes more important: All code on AIX is position independent (PIC) by default. Executables and shared libraries essentially are PIE. Because of this, AIX does not provide separate static libraries and one can link statically with a shared library. Creating a library enabled for runtime linking with -G (-brtl), causes a lot of problems, including a newly recognized failure mode. Without careful control over AIX symbol export, all global calls with use glink code (equivalent to ELF PLTs). This also creates a TOC entry for every global call, possibly overflowing the TOC. About to define careful control over AIX symbol export: The symbols listed in the import file are those found in the object files only, not the ones created at linktime (like __GLOBAL*) or from the static objects found in libc.a. While I do this in libtool from the beginning here, I have had a helper script wrapping ld to support '--soname=' for non-libtool packages, where creating the import file from the final shared object also included static libc-provided symbols, which turned out as dependency pitfall. AIX added ELF-like visibility support to XCOFF, which would be preferred. Except it was not added in a formal release, like AIX 8.1 and apparently was back-ported to at least AIX 6.1, so its difficult to phase in the support. One would need to add a configure test for the feature and not all users are upgrading the system. So one cannot build and distribute GCC for AIX 7.1 and know the feature is available in the system tools. GCC builds would be incompatible and object files, libraries, executables created by GCC would be incompatible. Basically, a mess. As I've seen the weak information on an older AIX 5.3 TL8 already: Is this visibility support something different than what nm -l or nm -P shows? While I haven't focussed on nor explicitly tested, I do believe that this also solves problems with global C++ constructor/destructor call orders. Why? There still is the problem of the AIX kernel runtime loader ordering dependent shared objects. Feels like I indeed haven't digged deep enough into that topic yet: To be ignored here then. But the main problem is GCC uses aliases and functions declared as weak to support some C++ features. This is another reason why I do force runtime linking for our application, which uses these C++ features while its main target platform is Linux. You have not explained how this has any fix / benefit affecting the problem, other than separate shared and static libraries. Forcing runtime linking seems irrelevant. It was linking shared before and linking shared after your patch (with runtime linking) so the net effect is zero. My main reason here is to allow for *filename*-based sharedlib versioning, which I haven't been able to achive without import files. In-archive versioning is a pita from a package manager's point of view. For a second reason: Due to its Linux-centric history (well, HP-UX and Solaris before), our application architecture does rely on runtime linking in some corner cases. This is why I force that for AIX in our development- and runtime-platform, which is similar to /opt/freeware/, but based on Gentoo Prefix. For a third reason (maybe I don't have deep enough insight as well): If I understand correctly, you switched to build libstdc++ without runtime linking, because of problems when linking statically against the rtl-enabled libstdc++, no? For this case, by incident aix-soname does prevent shared objects built with runtime linking from being statically linked. For another reason: I can imaging to provide an rtl_enable'd libc.so as well, to allow for easier use of memory debuggers that intercept the malloc/free co libc calls... But AFAICT these rely on every sharedlib to be built with runtime linking enabled. Again, runtime linking of all global symbols affects performance and bloats the TOC, making TOC overflow more
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
On 11/11/2014 04:02 PM, David Edelsohn wrote: Michael, Why does the configure change match with p*-*-aix... instead of power* or powerpc*? Yes, it's unique and will match, but why make it as short as possible, which doesn't match other uses? Actually I did have powerpc* initially, but gmp-6.0.0 config.guess'ed power7-ibm-aix6.1.0.0 now. Then I've thought that one may use ppc as well, but now I see this config.sub's to powerpc anyway, so power* is fine. Patch updated. In your documentation, how are you distinguishing between Dynamic Linking and Runtime Linking? I've tried to use the same naming scheme as in the ld Command Reference and the dlopen Subroutine man pages. Actually, there is at linktime: Dynamic Linking: also known as Dynamic Mode or (more common) Shared Linking: record a shared object's name into the created binary at runtime: Runtime Loading: load these shared objects at process startup Runtime Linking: resolve the symbols after loading shared objects Dynamic Loading: load shared objects by application logic with dlopen() I'm unsure how to make this as clear as possible though. Thanks! /haubi/ Thanks, David On Mon, Nov 10, 2014 at 12:41 PM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-10 17:06, schrieb David Edelsohn: On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-07 20:52, schrieb David Edelsohn: First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches. I don't have a fundamental objection to including this option, but note that Richi, Honza and I have discovered that using AIX runtime linking option interacts badly with some GCC optimizations and can result in applications that hang in a loop. Feels like adding the aix-soname linking procedure becomes more important: All code on AIX is position independent (PIC) by default. Executables and shared libraries essentially are PIE. Because of this, AIX does not provide separate static libraries and one can link statically with a shared library. Creating a library enabled for runtime linking with -G (-brtl), causes a lot of problems, including a newly recognized failure mode. Without careful control over AIX symbol export, all global calls with use glink code (equivalent to ELF PLTs). This also creates a TOC entry for every global call, possibly overflowing the TOC. About to define careful control over AIX symbol export: The symbols listed in the import file are those found in the object files only, not the ones created at linktime (like __GLOBAL*) or from the static objects found in libc.a. While I do this in libtool from the beginning here, I have had a helper script wrapping ld to support '--soname=' for non-libtool packages, where creating the import file from the final shared object also included static libc-provided symbols, which turned out as dependency pitfall. AIX added ELF-like visibility support to XCOFF, which would be preferred. Except it was not added in a formal release, like AIX 8.1 and apparently was back-ported to at least AIX 6.1, so its difficult to phase in the support. One would need to add a configure test for the feature and not all users are upgrading the system. So one cannot build and distribute GCC for AIX 7.1 and know the feature is available in the system tools. GCC builds would be incompatible and object files, libraries, executables created by GCC would be incompatible. Basically, a mess. As I've seen the weak information on an older AIX 5.3 TL8 already: Is this visibility support something different than what nm -l or nm -P shows? While I haven't focussed on nor explicitly tested, I do believe that this also solves problems with global C++ constructor/destructor call orders. Why? There still is the problem of the AIX kernel runtime loader ordering dependent shared objects. Feels like I indeed haven't digged deep enough into that topic yet: To be ignored here then. But the main problem is GCC uses aliases and functions declared as weak to support some C++ features. This is another reason why I do force runtime linking for our application, which uses these C++ features while its main target platform is Linux. You have not explained how this has any fix / benefit affecting the problem, other than separate shared and static libraries. Forcing runtime linking seems irrelevant. It was linking shared before and linking shared after your patch (with runtime linking) so the net effect is zero. My main reason here is to allow for *filename*-based sharedlib versioning, which I haven't been able to achive without import files. In-archive versioning is a pita from a package manager's point of view. For a second reason: Due to its Linux-centric history (well, HP-UX and Solaris before), our application architecture does rely on runtime linking in some corner cases. This is why
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
Am 2014-11-07 20:52, schrieb David Edelsohn:
First, please explicitly copy me on AIX or PowerPC patches sent to
gcc-patches.
I don't have a fundamental objection to including this option, but
note that Richi, Honza and I have discovered that using AIX runtime
linking option interacts badly with some GCC optimizations and can
result in applications that hang in a loop.
Feels like adding the aix-soname linking procedure becomes more important:
All code on AIX is position independent (PIC) by default. Executables
and shared libraries essentially are PIE. Because of this, AIX does
not provide separate static libraries and one can link statically
with a shared library.
Creating a library enabled for runtime linking with -G (-brtl), causes
a lot of problems, including a newly recognized failure mode. Without
careful control over AIX symbol export, all global calls with use
glink code (equivalent to ELF PLTs). This also creates a TOC entry for
every global call, possibly overflowing the TOC.
About to define careful control over AIX symbol export:
The symbols listed in the import file are those found in the object files
only, not the ones created at linktime (like __GLOBAL*) or from the static
objects found in libc.a. While I do this in libtool from the beginning here,
I have had a helper script wrapping ld to support '--soname=' for non-libtool
packages, where creating the import file from the final shared object also
included static libc-provided symbols, which turned out as dependency pitfall.
While I haven't focussed on nor explicitly tested, I do believe that this
also solves problems with global C++ constructor/destructor call orders.
But the main problem is GCC uses aliases and functions declared as
weak to support some C++ features.
This is another reason why I do force runtime linking for our application,
which uses these C++ features while its main target platform is Linux.
Functions declared weak interact
badly with shared libraries compiled for AIX runtime linking and
linked statically.
The aix-soname proposal does not support statically linking shared objects
built with -brtl, but provides lib.a archives either with pure static objects
only (aix-soname=svr4), or with the traditional shared object linked without
-brtl (aix-soname=both).
This can result in the static binary binding with
the glink code that loads its own address from the TOC instead of the
target function, causing endless looping. Honza made some changes to
GCC code generation for AIX, but there still are problems and I have
disabled building libstdc++ enabled for runtime linking.
So as long as shared objects built with -brtl actually work for /shared/
linking,
the aix-soname linking procedure seems /necessary/ to support all features.
libgcc always explicitly creates a static library and uses it for
static linking. All shared libraries for AIX that use this scheme
(through libtool) would have to follow the same convention to create
both shared and static libraries. This new option only makes sense if
it fully emulates SVR4/ELF behavior and always creates both shared .so
and static .a libraries.
This exactly is what I do in Gentoo Prefix/AIX, with best experience using
gcc-4.2.4 for the moment. As I do provide the complete tool- library-chain
(like /opt/freeware/), I don't create traditional AIX shared objects at all,
but static only lib.a archives whenever --enable-static is true - which is
the --with-aix-soname=svr4 use case.
Slightly modified the patch to not create the libgcc_s.a symlink with
aix-soname=svr4 now.
And the Makefile target also has to be libgcc_s.so (via SHLIB_EXT) now.
Thanks!
/haubi/
From ab834013e504ddfbbc0a04aca2bd94ef0b49ace5 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner michael.haubenwall...@salomon.at
Date: Fri, 16 Mar 2012 14:49:20 +0100
Subject: [PATCH] AIX: Filename-based shlib versioning for libgcc_s
2014-11-10 Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com
(libgcc_s) Optional filename-based shared library versioning on AIX.
* gcc/doc/install.texi: Describe --with-aix-soname option.
* Makefile.in (with_aix_soname): Define.
* config/rs6000/t-slibgcc-aix: Act upon --with-aix-soname option.
* configure.in: Accept --with-aix-soname=aix|svr4|both option.
* configure: Recreate.
---
gcc/doc/install.texi | 102 +
libgcc/Makefile.in | 1 +
libgcc/config/rs6000/t-slibgcc-aix | 82 +++--
libgcc/configure | 28 ++
libgcc/configure.ac| 17 +++
5 files changed, 214 insertions(+), 16 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 3df78ff..161f7e5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1414,6 +1414,102 @@ particularly useful if you intend to use several versions of GCC in
parallel. This is currently supported by @samp{libgfortran},
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-07 20:52, schrieb David Edelsohn: First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches. I don't have a fundamental objection to including this option, but note that Richi, Honza and I have discovered that using AIX runtime linking option interacts badly with some GCC optimizations and can result in applications that hang in a loop. Feels like adding the aix-soname linking procedure becomes more important: All code on AIX is position independent (PIC) by default. Executables and shared libraries essentially are PIE. Because of this, AIX does not provide separate static libraries and one can link statically with a shared library. Creating a library enabled for runtime linking with -G (-brtl), causes a lot of problems, including a newly recognized failure mode. Without careful control over AIX symbol export, all global calls with use glink code (equivalent to ELF PLTs). This also creates a TOC entry for every global call, possibly overflowing the TOC. About to define careful control over AIX symbol export: The symbols listed in the import file are those found in the object files only, not the ones created at linktime (like __GLOBAL*) or from the static objects found in libc.a. While I do this in libtool from the beginning here, I have had a helper script wrapping ld to support '--soname=' for non-libtool packages, where creating the import file from the final shared object also included static libc-provided symbols, which turned out as dependency pitfall. AIX added ELF-like visibility support to XCOFF, which would be preferred. Except it was not added in a formal release, like AIX 8.1 and apparently was back-ported to at least AIX 6.1, so its difficult to phase in the support. One would need to add a configure test for the feature and not all users are upgrading the system. So one cannot build and distribute GCC for AIX 7.1 and know the feature is available in the system tools. GCC builds would be incompatible and object files, libraries, executables created by GCC would be incompatible. Basically, a mess. While I haven't focussed on nor explicitly tested, I do believe that this also solves problems with global C++ constructor/destructor call orders. Why? There still is the problem of the AIX kernel runtime loader ordering dependent shared objects. But the main problem is GCC uses aliases and functions declared as weak to support some C++ features. This is another reason why I do force runtime linking for our application, which uses these C++ features while its main target platform is Linux. You have not explained how this has any fix / benefit affecting the problem, other than separate shared and static libraries. Forcing runtime linking seems irrelevant. It was linking shared before and linking shared after your patch (with runtime linking) so the net effect is zero. Again, runtime linking of all global symbols affects performance and bloats the TOC, making TOC overflow more likely. I don't have a fundamental objection to the patch, but you have not really responded to the potential problems and any motivation for this feature other than greater SVR4 emulation. For better or worse, AIX is not SVR4. Every library built with this option hurts performance on AIX and potentially causes mysterious TOC overflow errors, which confuse users unfamiliar with AIX and whose workarounds hurt performance even more. Thanks, David
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
Am 2014-11-10 17:06, schrieb David Edelsohn: On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Am 2014-11-07 20:52, schrieb David Edelsohn: First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches. I don't have a fundamental objection to including this option, but note that Richi, Honza and I have discovered that using AIX runtime linking option interacts badly with some GCC optimizations and can result in applications that hang in a loop. Feels like adding the aix-soname linking procedure becomes more important: All code on AIX is position independent (PIC) by default. Executables and shared libraries essentially are PIE. Because of this, AIX does not provide separate static libraries and one can link statically with a shared library. Creating a library enabled for runtime linking with -G (-brtl), causes a lot of problems, including a newly recognized failure mode. Without careful control over AIX symbol export, all global calls with use glink code (equivalent to ELF PLTs). This also creates a TOC entry for every global call, possibly overflowing the TOC. About to define careful control over AIX symbol export: The symbols listed in the import file are those found in the object files only, not the ones created at linktime (like __GLOBAL*) or from the static objects found in libc.a. While I do this in libtool from the beginning here, I have had a helper script wrapping ld to support '--soname=' for non-libtool packages, where creating the import file from the final shared object also included static libc-provided symbols, which turned out as dependency pitfall. AIX added ELF-like visibility support to XCOFF, which would be preferred. Except it was not added in a formal release, like AIX 8.1 and apparently was back-ported to at least AIX 6.1, so its difficult to phase in the support. One would need to add a configure test for the feature and not all users are upgrading the system. So one cannot build and distribute GCC for AIX 7.1 and know the feature is available in the system tools. GCC builds would be incompatible and object files, libraries, executables created by GCC would be incompatible. Basically, a mess. As I've seen the weak information on an older AIX 5.3 TL8 already: Is this visibility support something different than what nm -l or nm -P shows? While I haven't focussed on nor explicitly tested, I do believe that this also solves problems with global C++ constructor/destructor call orders. Why? There still is the problem of the AIX kernel runtime loader ordering dependent shared objects. Feels like I indeed haven't digged deep enough into that topic yet: To be ignored here then. But the main problem is GCC uses aliases and functions declared as weak to support some C++ features. This is another reason why I do force runtime linking for our application, which uses these C++ features while its main target platform is Linux. You have not explained how this has any fix / benefit affecting the problem, other than separate shared and static libraries. Forcing runtime linking seems irrelevant. It was linking shared before and linking shared after your patch (with runtime linking) so the net effect is zero. My main reason here is to allow for *filename*-based sharedlib versioning, which I haven't been able to achive without import files. In-archive versioning is a pita from a package manager's point of view. For a second reason: Due to its Linux-centric history (well, HP-UX and Solaris before), our application architecture does rely on runtime linking in some corner cases. This is why I force that for AIX in our development- and runtime-platform, which is similar to /opt/freeware/, but based on Gentoo Prefix. For a third reason (maybe I don't have deep enough insight as well): If I understand correctly, you switched to build libstdc++ without runtime linking, because of problems when linking statically against the rtl-enabled libstdc++, no? For this case, by incident aix-soname does prevent shared objects built with runtime linking from being statically linked. For another reason: I can imaging to provide an rtl_enable'd libc.so as well, to allow for easier use of memory debuggers that intercept the malloc/free co libc calls... But AFAICT these rely on every sharedlib to be built with runtime linking enabled. Again, runtime linking of all global symbols affects performance and bloats the TOC, making TOC overflow more likely. Well, I don't have need to care for performance that much. So do I force -mminimal-toc as well, where the only reason I have seen so far to avoid the -bbigtoc linker flag instead is that gdb has problems with that. I don't have a fundamental objection to the patch, but you have not really responded to the potential problems and any motivation for this feature other than greater SVR4 emulation. For better or worse, AIX is
[PATCH] AIX: Filename-based shared library versioning for libgcc_s
Hi David (et al)!
The upcoming initial release of gcc-5 feels like a good opportunity for the
AIX port of gcc to introduce optional support for the important Linux-known
feature I'd call filename-based shared library versioning, aka. SONAME.
We have had some discussion in https://gcc.gnu.org/PR52623 already, and I've
found it most descriptive for the configure option to read:
--with-aix-soname=aix|svr4|both
where 'aix' is the current situation (default), 'svr4' the new variant only,
and 'both' for backwards compatibility - outlined in the install.texi diff.
To allow for backwards compatibility at all, I'd provide the 'svr4' variant
with 'runtime linking' enabled only, as this is true for Linux/SVR4 anyway.
As I'm using the 'svr4' variant for a quite large portable C/C++ application
already (via Gentoo Prefix) on AIX, I can tell this kind of filename-based
versioning of shared libraries does really work as expected.
Besides adding some documentation, attached patch is for libgcc_s only, as for
other libraries I'd prefer to get the --with-aix-soname support via upstream
libtool, where I don't have the 'both'-support ready yet. I have to rebase
the existing 'svr4' patches anyway - currently these do --enable-aix-soname,
found in https://github.com/haubi/libtool/compare/aix-soname
But even if not ready for normal use yet, I'd love to see the gcc-5 release
start introducing 'aix-soname' - allowing for more Linux with AIX ;)
Thoughts?
Thank you!
/haubi/
From 9f6fd44eddf3b0c43f0472c172d6420b8b91b7db Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner michael.haubenwall...@salomon.at
Date: Fri, 16 Mar 2012 14:49:20 +0100
Subject: [PATCH] AIX: Filename-based shlib versioning for libgcc_s
2012-11-05 Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com
(libgcc_s) Optional filename-based shared library versioning on AIX.
* gcc/doc/install.texi: Describe --with-aix-soname option.
* Makefile.in (with_aix_soname): Define.
* config/rs6000/t-slibgcc-aix: Support filename-based versioning.
* configure.in: Accept --with-aix-soname=aix|svr4|both option.
* configure: Recreate.
---
gcc/doc/install.texi | 102 +
libgcc/Makefile.in | 1 +
libgcc/config/rs6000/t-slibgcc-aix | 86 +--
libgcc/configure | 28 ++
libgcc/configure.ac| 17 +++
5 files changed, 219 insertions(+), 15 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 3df78ff..161f7e5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1414,6 +1414,102 @@ particularly useful if you intend to use several versions of GCC in
parallel. This is currently supported by @samp{libgfortran},
@samp{libjava}, @samp{libstdc++}, and @samp{libobjc}.
+@item @anchor{WithAixSoname}--with-aix-soname=@samp{aix}, @samp{svr4} or @samp{both}
+Traditional AIX shared library versioning (versioned @code{Shared Object}
+files as members of unversioned @code{Archive Library} files named
+@samp{lib.a}) causes numerous headaches for package managers. However,
+@code{Import Files} as members of @code{Archive Library} files allow for
+@strong{filename-based versioning} of shared libraries as seen on Linux/SVR4,
+where this is called the SONAME. But as they prevent static linking,
+@code{Import Files} may be used with @code{Runtime Linking} only, where the
+linker does search for @samp{libNAME.so} before @samp{libNAME.a} library
+filenames with the @samp{-lNAME} linker flag.
+
+@anchor{AixLdCommand}For detailed information please refer to the AIX
+@uref{http://www-01.ibm.com/support/knowledgecenter/search/%22the%20ld%20command%2C%20also%20called%20the%20linkage%20editor%20or%20binder%22,,ld
+Command} reference.
+
+As long as shared library creation is enabled, upon:
+@table @code
+@item --with-aix-soname=aix
+@item --with-aix-soname=both
+ A (traditional AIX) @code{Shared Archive Library} file is created:
+ @itemize @bullet
+ @item using the @samp{libNAME.a} filename scheme
+ @item with the @code{Shared Object} file as archive member named
+ @samp{libNAME.so.V} (except for @samp{libgcc_s}, where the @code{Shared
+ Object} file is named @samp{shr.o} for backwards compatibility), which
+ @itemize @minus
+ @item is used for runtime loading from inside the @samp{libNAME.a} file
+ @item is used for dynamic loading via
+ @code{dlopen(libNAME.a(libNAME.so.V), RTLD_MEMBER)}
+ @item is used for shared linking
+ @item is used for static linking, so no separate @code{Static Archive
+ Library} file is needed
+ @end itemize
+ @end itemize
+@item --with-aix-soname=both
+@item --with-aix-soname=svr4
+ A (second) @code{Shared Archive Library} file is created:
+ @itemize @bullet
+ @item using the @samp{libNAME.so.V} filename scheme
+ @item with the @code{Shared Object} file as archive member named
+ @samp{shr.o}, which
+ @itemize @minus
+ @item is created with the @code{-G linker flag}
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches. I don't have a fundamental objection to including this option, but note that Richi, Honza and I have discovered that using AIX runtime linking option interacts badly with some GCC optimizations and can result in applications that hang in a loop. All code on AIX is position independent (PIC) by default. Executables and shared libraries essentially are PIE. Because of this, AIX does not provide separate static libraries and one can link statically with a shared library. Creating a library enabled for runtime linking with -G (-brtl), causes a lot of problems, including a newly recognized failure mode. Without careful control over AIX symbol export, all global calls with use glink code (equivalent to ELF PLTs). This also creates a TOC entry for every global call, possibly overflowing the TOC. But the main problem is GCC uses aliases and functions declared as weak to support some C++ features. Functions declared weak interact badly with shared libraries compiled for AIX runtime linking and linked statically. This can result in the static binary binding with the glink code that loads its own address from the TOC instead of the target function, causing endless looping. Honza made some changes to GCC code generation for AIX, but there still are problems and I have disabled building libstdc++ enabled for runtime linking. libgcc always explicitly creates a static library and uses it for static linking. All shared libraries for AIX that use this scheme (through libtool) would have to follow the same convention to create both shared and static libraries. This new option only makes sense if it fully emulates SVR4/ELF behavior and always creates both shared .so and static .a libraries. Thanks, David
