Re: Additional link flags for HP aCC and SGI CC

[Bob Friesenhahn]

On Fri, 3 Sep 2004, Albert Chin wrote:
> > 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.

I take it that this means you agree with my statement?  Focus on 
portable behavior, but flags are arbitrary?

> -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.

Did you mean "why should we" or "why shouldn't we"?

If libtool takes responsibility for 32/64 bit build knowledge, then it 
must/should also assume responsibility for associated multilib naming 
conventions and installation directory conventions.  This is fine as 
far as I am concerned, but it goes far beyond the scope of the 
forthcoming libtool release.

For SPARC/Solaris, GCC knows about three different library variants. 
There are probably more variants than this for the MIPS processor 
family.

Whether all compile-time compiler options should be passed on to the 
compiler *is* something which should be considered for the forthcoming 
release.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen