This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
- From: "michael.haubenwallner at salomon dot at" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 28 Mar 2012 08:21:37 +0000
- Subject: [Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
- Auto-submitted: auto-generated
- References: <bug-52623-4@http.gcc.gnu.org/bugzilla/>
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!