[Bug bootstrap/52623] New: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[Bug bootstrap/52623] New: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

             Bug #: 52623
           Summary: 4.7.0-RC-20120314: bootstrap failure on AIX due to
                    multilib and using C++ in post-stage1
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: michael.haubenwallner@salomon.at
              Host: powerpc-ibm-aix7.1.0.0
            Target: powerpc-ibm-aix7.1.0.0
             Build: powerpc-ibm-aix7.1.0.0


Created attachment 26923
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26923
Output of 'gmake bootstrap' (single job)

Bootstrapping gcc-4.7.0-RC-20120314 on powerpc-ibm-aix7.1.0.0 fails because of
32bit gcc/xgcc cannot load a 64bit libstdc++.a.

It works when I do configure with --disable-build-poststage1-with-cxx

Prerequisites:

Installed binary:
  gcc-4.6.2 in /opt/freeware/ from perzl.org,
Self-built:
  gmp-5.0.1, configured with ABI=32
  mpfr-3.0.0,
  mpc-0.8.2,

Toplevel configured with --enable-languages=c,c++
'gmake bootstrap' with single job

The last lines in the output of 'gmake bootstrap' (from attached
bootstrap.out.bz2):

---
Adding multilib support to Makefile in
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath
with_multisubdir=pthread
Running configure in multilib subdir ppc64
pwd:
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0
configure: creating cache ./config.cache
checking build system type... powerpc-ibm-aix7.1.0.0
checking host system type... powerpc-ibm-aix7.1.0.0
checking target system type... powerpc-ibm-aix7.1.0.0
checking for a BSD-compatible install...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/install-sh
-c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath/../install-sh
-c -d
checking for gawk... nawk
checking whether gmake sets $(MAKE)... yes
checking for --enable-version-specific-runtime-libs... no
checking for style of include used by gmake... GNU
checking for powerpc-ibm-aix7.1.0.0-gcc...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include
 -maix64
checking for suffix of object files... configure: error: in
`/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libquadmath':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[1]: *** [configure-target-libquadmath] Error 1
gmake[1]: Leaving directory
`/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build'
gmake: *** [bootstrap] Error 2
---

The interesting lines in powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log
(attached as powerpc-ibm-aix7.1.0.0_ppc64_libquadmath_config.log.bz2):

---
configure:3239: checking for C compiler version
configure:3248: /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include
 -maix64 --version >&5
Could not load program
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc:
        Dependent module
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6)
could not be loaded.
        The module has an invalid magic number.
configure:3259: $? = 255
---

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #1 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-19 17:20:23 UTC ---
Created attachment 26924
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26924
powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-20
     Ever Confirmed|0                           |1

--- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-20 14:12:00 UTC ---
We should disable libquadmath on AIX.  It is not needed or useful there.

Have you tried adding --disable-libquadmath when configuring GCC?

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #3 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-21 09:38:00 UTC ---
(In reply to comment #2)
> We should disable libquadmath on AIX.  It is not needed or useful there.
> 
> Have you tried adding --disable-libquadmath when configuring GCC?

For --enable-languages=c,c++ only, I can bootstrap using --disable-libquadmath.
Haven't tried other languages needing their own target libraries.

But the problem isn't with libquadmath itself, but with config-ml.in setting
LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting enough)
the AIX 7.1 loader listening to LD_LIBRARY_PATH now.

Consider these simple commands to trigger the configure-error in
ppc64/libquadmath:

$ ./gcc/xgcc
xgcc: fatal error: no input files
compilation terminated.

$ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs
./gcc/xgcc
exec(): 0509-036 Cannot load program ./gcc/xgcc because of the following
errors:
        0509-150   Dependent module
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6)
could not be loaded.
        0509-103   The module has an invalid magic number.

Unfortunately, the AIX loader stops searching at the first matching archive
filename found,
even if it doesn't contain a matching shared object.


However, ldd shipped with AIX 7.1 still ignores LD_LIBRARY_PATH:

$ ldd ./gcc/xgcc
./gcc/xgcc needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libiconv.a(shr4.o)
        
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6)
         /unix
         /usr/lib/libcrypt.a(shr.o)
        
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o)

$ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs ldd
./gcc/xgcc
./gcc/xgcc needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libiconv.a(shr4.o)
        
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6)
         /unix
         /usr/lib/libcrypt.a(shr.o)
        
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o)

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #4 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-21 14:27:06 UTC ---
(In reply to comment #3)
> But the problem isn't with libquadmath itself, but with config-ml.in setting
> LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting enough)
> the AIX 7.1 loader listening to LD_LIBRARY_PATH now.

This is bug#46981 actually.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #5 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-22 03:00:40 UTC ---
AIX fundamentally wants to handle shared objects differently than
SVR4/Solaris/Linux.  AIX wants to package shared objects in an archive, like
normal object files.  And AIX library versioning happens within an archive --
all but the newest shared object are marked LOADONLY using the AIX "strip -e"
command.  Similarly an archive can contain both 32 bit and 64 bit objects.

That design does not match multiple shared objects in a directory and separate
directories for 32 bit and 64 bit.  It also leads to an algorithm design that
stops at the first archive found, which conflicts with GCC trying to
accommodate Linux's SVR4 design.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #6 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-22 09:10:29 UTC ---
Traditionally, yes.

However, there are Import Files:
They can definitively help for the versioning issue,
and can probably help for the multilib issue too.

However, they cannot be used for static linking, so we might want to use them
with the "-brtl" linker flag only (which would be enabled by "-bsvr4" too).

I'm planning to start an RFC on the gcc-ml soon...

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #7 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-22 19:02:23 UTC ---
Can you be a little more specific about how you want to use import files?  You
seem to be associating them with -brtl, but that is a separate issue.

GCC -shared and AIX support shared libraries by default, without -brtl. 
Traditionally, AIX shared libraries are archives of shared object files, e.g.,
shr.o, shr4.o, etc.  One may link against libfoo.a containing shared objects,
but the result is dynamic linking.

What AIX does not support by default is overriding symbols at runtime. 
Creating the shared object with -G and linking the executable with -brtl adds
support for dynamic runtime overrides, like SVR4.  -brtl also adds ".so" files
to the search path so that a shared object can be named libfoo.so instead of
libfoo.a.  There also are differences in which symbols are exported by default.

But the basic support for shared libraries exists without -brtl or -bsvr4.

An export file explicitly informs the linker which symbols should be exported
and visible in a shared library.  AIX normally does not export symbols that
begin with an underscore, which occurs often in C++ mangling.

An import file is a list of symbols are exported by a shared library or
executable.  The linker implicitly generates an import file when linking
against a shared library.  An import file also provides some flexibility for
wildcards about the source of the symbol, e.g., the symbol will be provided by
the main application or by run-time linking.

Are you trying to use import files to change the search path or search order?

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #8 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-22 20:33:01 UTC ---
I'm still grafting some RFC for gcc-ml with more background info for the
not-so-experienced ones, however I don't mind to discuss that here - eventually
resulting in a better RFC if still needed afterwards.

This is how I'm successfully using Import Files already, to provide the soname
feature with runtime linking enabled:

* Create the list of exported symbols from object files.
  but with extra "weak" keyword, for the import file later.
* Create shr.o using -G linker flag, using that list of exported symbols.
* Set F_LOADONLY on shr.o.
* Create shr.imp, where
    first line is the "soname":    #! libNAME.so.1(shr.o)
    second line is the bitwidth:   # 32
    rest is list of symbols:       symbol
    eventually flagged as weak:    weak_symbol weak
* Create libNAME.so.1 as archive, containing shr.o and shr.imp
* Create symlink libNAME.so -> libNAME.so.1

The reason I do this with -brtl only is that this variant doesn't allow to
statically link shr.o any more, so I cannot create libNAME.a this way.

While I do not use multilib here, the file format still allows for the AIX way
of multilib, with these differences to the above for 64bit:

* Create shr_64.o
* Create shr_64.imp
* Specify "# 64" in shr_64.imp

Finally, libNAME.so.1 would contain:
  shr.o
  shr.imp
  shr_64.o
  shr_64.imp

The name of the archive members is just some convention to avoid confusion, AIX
would allow for more than one archive member with identical name, especially if
they are shared objects with different bitwidth, using the -X32 and -X64
toolchain flags.

What /really/ matters is the second line in the import file to read:
  # 64

You're welcome to read the history on how I've sorted out this variant:
http://bugs.gentoo.org/213277

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #9 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-22 21:23:46 UTC ---
Yes, one can re-engineer the GCC and libtool shared library build process on
AIX to try to make AIX look more like SVR4.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-22 23:53:14 UTC ---
I recognize that a lot of FLOSS packages are developed on x86/Linux, but
POWER/AIX is not x86/Linux.  Upon further consideration, I am concerned that
your proposal forces all applications to link using -brtl.  Your proposal
implies that libtool and GCC should build all shared libraries using your
SVR4-compatibility design.  One could adjust GCC and libtool to link all
applications with -brtl, but libraries built the current way can work with
older releases of GCC and with XLC.  Even with the GCC change, many users will
be confused by XLC breakage and it will be a steep learning curve to teach
users to add -brtl to all applications that use newly-built FLOSS libraries
using the new libtool design.

I agree that AIX is gratuitously different from SVR4/Solaris/Linux with no
particular benefit.  However, it is what it is.  Without cooperation from IBM
and AIX to convert it to SVR4-compatibility by default, I'm not convinced that
imposing this compatibility is a good idea when the GNU tools do not control
the entire system stack.

An additional problem is Binutils "strip" command does not support the -e/-E
command line option to set F_LOADONLY.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #11 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-23 09:31:41 UTC ---
Unless IBM does, I don't want to change any default here, nor force anyone to
use -brtl.

What I'm after is:
Give package managers another choice how to build the packages, out of:
  A: libNAME.a(libNAME.so.1)     (libtool default)
  B: libNAME.so                  (supported by libtool)
  C: libNAME.so.1(shr.o)         (new)
Using autoconf+libtool, the variants could be selected using:
  A    : default (same as --disable-aix-svr4)
  A B  : LDFLAGS=-Wl,-brtl
    B  : LDFLAGS=-Wl,-brtl --disable-static
  A   C: --enable-aix-svr4
      C: --enable-aix-svr4 --disable-static

(*able-aix-svr4 feels more correct than *able-aix-soname)

For the FLOSS developers:
Most of them don't care AIX (among others) at all. However, they use libtool
(or something else) that allows them to not care.

For XLC:
There is nothing specific to GCC, Import Files work with XLC too, and I don't
want to change anything within collect2 or GNU-ld - just the build-scripts
(libtool&co).

For multilib:
I've seen package managers building a package twice, and merge both
"(libNAME.so.1)" into "libNAME.a".
This works for A as well as C, but does not work for B.

(In reply to comment #10)
> An additional problem is Binutils "strip" command does not support the -e/-E
> command line option to set F_LOADONLY.

This should be fixed anyway.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #12 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-23 10:29:15 UTC ---
(In reply to comment #11)
> Give package managers another choice how to build the packages, out of:
>   A: libNAME.a(libNAME.so.1)     (libtool default)
>   B: libNAME.so                  (supported by libtool)
>   C: libNAME.so.1(shr.o)         (new)
> Using autoconf+libtool, the variants could be selected using:
>   A    : default (same as --disable-aix-svr4)

Err, aix-svr4 chooses between B or C only, so this should read:

    A    : default
>   A B  : LDFLAGS=-Wl,-brtl
>     B  : LDFLAGS=-Wl,-brtl --disable-static
>   A   C: --enable-aix-svr4
>       C: --enable-aix-svr4 --disable-static

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #13 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-23 16:39:53 UTC ---
Hmm, err, A and B aren't created at the same time by libtool.
Instead, this table really should include static-only libs too:

(S)tatic: libNAME.a(static.o)
(A)ix:    libNAME.a(libNAME.so.1)
(B)roken: libNAME.so
(L)inux:  libNAME.so.1(shr.o)

         | (default:yes) | (default:yes) |  (default:no)   | (default:"") |
         | enable-static | enable-shared | enable-aix-svr4 |   LDFLAGS    |
--+------+---------------+---------------+-----------------+--------------+
1 | S    :     yes       |     no        |   irrelevant    |  irrelevant  |
2 |  A   :     yes       |     yes       |      no         |      ""      |
3 | S B  :     yes       |     yes       |      no         |   "-brtl"    |
4 |   B  :     no        |     yes       |      no         |   "-brtl"    |
5 |  A L :     yes       |     yes       |    compat       |  irrelevant  |
6 | S  L :     yes       |     yes       |     yes         |  irrelevant  |
7 |    L :     no        |     yes       |     yes         |  irrelevant  |
--+------+---------------+---------------+-----------------+--------------+

Besides shared and/or static, package managers would have a choice of three:
 1 and 2: traditional AIX only
(3 and 4: broken)
    5   : SVR4 with compatibility to traditional AIX
 6 and 7: SVR4 only

But - first of all:
Besides those administrative issues, do you see any technical issue why Import
Files cannot be used this way for filename-based versioning over the
traditional onefile-membername-based versioning?

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #14 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-27 16:38:15 UTC ---
> Do you see any technical issue why Import
> Files cannot be used this way for filename-based versioning over the
> traditional onefile-membername-based versioning?

I think that import files can be used the way you suggest.

I am not sure I understand why you write that libNAME.so is broken.  AIX can
search for a bare shared object named libNAME.so.

Also, I still believe that your "Linux" solution will require linking with
-brtl or -bsvr4.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #15 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-28 08:21:37 UTC ---
(In reply to comment #14)
> > Do you see any technical issue why Import
> > Files cannot be used this way for filename-based versioning over the
> > traditional onefile-membername-based versioning?
> 
> I think that import files can be used the way you suggest.

Ok, thank you!

> I am not sure I understand why you write that libNAME.so is broken.  AIX can
> search for a bare shared object named libNAME.so.

It isn't broken in a technical sense from AIX' point of view,
it is broken in the package manager's point of view, not allowing for /any/
kind of versioning at all (neither via filename nor via archive member with
F_LOADONLY flag), as well as breaking multilib.

> Also, I still believe that your "Linux" solution will require linking with
> -brtl or -bsvr4.

Yes, and the main (because technical) reason is to keep static linking
possible.

This also is the reason I've named the commandline switch "*able-aix-svr4" for
now, but I don't have a hard opinion here, because
--disable-static _would_ allow (administrative-wise) for import files even
without -brtl/-bsvr4 (easiest via symlink libNAME.a -> libNAME.so.1).

As the name "aix-svr4" implies runtime linking, maybe "aix-soname" is more
suitable...

So - what I'm still unsure is:
*) how far to go with disable-static (symlink libNAME.a->libNAME.so.1),
   maybe upon aix-svr4=compat only?
*) which name and values for the configure-switch are as obvious as possible:
   1 : --enable-aix-svr4=[no | compat | yes]
   1l: --enable-aix-svr4=[no | yes | only]           # less forceful
   2 : --enable-aix-soname=[no | compat | yes]
   2l: --enable-aix-soname=[no | yes | only]         # less forceful
   3 : --with-aix-soname=[aix,no | both | svr4,yes]
   3l: --with-aix-soname=[aix,no | both,yes | svr4]  # less forceful

Where "less forceful" means to take 'yes' to provide both (A)ix+(L)inux,
needing 'only' to drop (A)ix,
while the others take 'yes' to provide (L)inux _only_, needing 'compat' or
'both' to provide (A)ix too.

Also, I'd like to _allow_ for package /maintainers/ to set either 'both' or
'only' (whichever name the values will have) as default value via LT_INIT
(usually upon some API/SONAME bump), while still allowing for package
/managers/ to override.

Using above names, this would be:
                for (A)ix+(L)inux                   for (L)inux only
(1 )  LT_INIT([ aix-svr4=compat   ])      LT_INIT([ aix-svr4        ])
(1l)  LT_INIT([ aix-svr4          ])      LT_INIT([ aix-svr4=only   ])
(2 )  LT_INIT([ aix-soname=compat ])      LT_INIT([ aix-soname      ])
(2l)  LT_INIT([ aix-soname        ])      LT_INIT([ aix-soname=only ])
(3 )  LT_INIT([ aix-soname=both   ])      LT_INIT([ aix-soname      ])
(3l)  LT_INIT([ aix-soname        ])      LT_INIT([ aix-soname=svr4 ])

More/better ideas?

Thank you!

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #16 from David Edelsohn <dje at gcc dot gnu.org> 2012-03-28 12:29:29 UTC ---
Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work?  I
seem to remember something strange about the way AIX loader followed symbolic
links.

For versioning one can use libNAME.1.so or libNAME-1.so -- as long as ".so" is
the file extension.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

--- Comment #17 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-03-28 14:20:52 UTC ---
(In reply to comment #16)
> Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work? I
> seem to remember something strange about the way AIX loader followed symbolic
> links.

The real (archive) file needs to be (available as) libNAME.so.1, which is what
the loader will search for. So there is no symbolic link involved at runtime,
unless we also do the libNAME.so.1 -> libNAME.so.1.2.3 symlink, which libtool
already does for the (B)roken variant.

Maybe these symlink troubles with the AIX loader are related to those .nfsXXX
files seen sometimes?

But still: Good to know we should not symlink libNAME.so.1 -> libNAME.so.1.2.3.

> For versioning one can use libNAME.1.so or libNAME-1.so -- as long as ".so" is
> the file extension.

This would imply to use '-lNAME.1' or '-lNAME-1' for the linker.
But the linker usually gets '-lNAME', hence libNAME.so (or libNAME.a) needs to
be available.

However, libNAME.so may be a symlink to libNAME.so.2 already, while
libNAME.so.1 is still around for binaries built when libNAME.so was a symlink
to libNAME.so.1.
(Isn't this what the SONAME is for at all?)

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedzsan at gmail dot com

--- Comment #18 from David Edelsohn <dje at gcc dot gnu.org> 2013-01-30 16:52:41 UTC ---
*** Bug 55105 has been marked as a duplicate of this bug. ***

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #19 from David Edelsohn <dje at gcc dot gnu.org> ---
Fixed