Bug 52623 - 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
Summary: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 55105 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-19 17:18 UTC by Michael Haubenwallner
Modified: 2015-02-06 16:01 UTC (History)
2 users (show)

See Also:
Host: powerpc-ibm-aix7.1.0.0
Target: powerpc-ibm-aix7.1.0.0
Build: powerpc-ibm-aix7.1.0.0
Known to work:
Known to fail:
Last reconfirmed: 2012-03-20 00:00:00


Attachments
Output of 'gmake bootstrap' (single job) (247.79 KB, application/x-bzip2)
2012-03-19 17:18 UTC, Michael Haubenwallner
Details
powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log (3.23 KB, application/x-bzip2)
2012-03-19 17:20 UTC, Michael Haubenwallner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Haubenwallner 2012-03-19 17:18:37 UTC
Created attachment 26923 [details]
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
---
Comment 1 Michael Haubenwallner 2012-03-19 17:20:23 UTC
Created attachment 26924 [details]
powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log
Comment 2 David Edelsohn 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?
Comment 3 Michael Haubenwallner 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)
Comment 4 Michael Haubenwallner 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.
Comment 5 David Edelsohn 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.
Comment 6 Michael Haubenwallner 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...
Comment 7 David Edelsohn 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?
Comment 8 Michael Haubenwallner 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
Comment 9 David Edelsohn 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.
Comment 10 David Edelsohn 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.
Comment 11 Michael Haubenwallner 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.
Comment 12 Michael Haubenwallner 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
Comment 13 Michael Haubenwallner 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?
Comment 14 David Edelsohn 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.
Comment 15 Michael Haubenwallner 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!
Comment 16 David Edelsohn 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.
Comment 17 Michael Haubenwallner 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?)
Comment 18 David Edelsohn 2013-01-30 16:52:41 UTC
*** Bug 55105 has been marked as a duplicate of this bug. ***
Comment 19 David Edelsohn 2015-02-06 16:01:15 UTC
Fixed