[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" <gcc-bugzilla at gcc dot gnu dot org>]

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?)