Re: Additional link flags for HP aCC and SGI CC

[Albert Chin]

On Fri, Sep 03, 2004 at 12:58:58PM -0500, Bob Friesenhahn wrote:
> On Fri, 3 Sep 2004, Gary V. Vaughan wrote:
> 
> >Albert Chin wrote:
> >>On Thu, Sep 02, 2004 at 06:04:44PM +0200, Ludovic Court?s wrote:
> >>The following patch will pass all -[arg] and +[arg] switches through.
> >>Is it safe?
> >
> >On a mostly philosophical point, I think that allowing arguments that
> >libtool doesn't recognize through to the compiler removes some of the
> >advantages that libtool brings to a project: it is the thin end of the
> >wedge to starting to put non-portable flags into Makefile.am.
> 
> What is wrong with using non-portable flags?  Why would non-portable 
> necessarily appear in Makefile.am rather than configure.ac?  The world 
> revolves around non-portable flags but it rejects non-portable 
> behavior.

Libtool is about portably creating archive/shared libraries. Having it
be a _uniform_ frontent to all supported C, C++, etc. compilers is,
methinks, a really really bad idea. I think libtool should recognize
the options that matter for it to do its job and pass everything else
through, barring some technical reason for why this is not possible.

> >Besides, you can already do this, but at the moment you have to do it
> >consciously and say `-Xcompiler -peculiar-flag-for-my-compiler', which
> >at least forces the user to acknowledge that they are going behind
> >libtool's back, so it will be hardly surprising to them if libtool gets
> >confused later on...
> 
> I suspect that you are unnecessarily limiting your development to the 
> Linux/GCC platform.  You may find it somewhat entertaining and 
> enlightening to accomplish non-default compilation (e.g. 64-bit) using 
> something other than GCC.  What you will learn is that -Xcompiler and 
> -Xlinker often confuses the build (e.g. building/linking partially 
> 32-bit/64-bit code) and that it takes a very careful incantation with 
> a very careful replication of -Xcompiler and -Xlinker options in the 
> right places in order to achieve success.  What I (and Albert) have 
> seen is that things can behave very poorly because the compiler 
> sometimes should alter its behavior based on linker options, but the 
> compiler does not pay attention to options it is instructed to blindly 
> pass through to the linker.

-Xcompiler and -Xlinker make sense only because it is sometimes common
to want a portable equivalent to -Wc/-Wl (and, if every compiler we
supported understood -Wc and/or -Wl, it'd drop the corresponding
libtool command-line equivalent). However, on Solaris, why should we
come up with a portable solution to creating 64-bit object files?
There are only two choices, the Sun compiler and GCC. Ditto for HP-UX,
IRIX, and AIX.

-- 
albert chin (address@hidden)