Re: Additional link flags for HP aCC and SGI CC

[Gary V. Vaughan]

Hi Ludovic,

Ludovic Courtès wrote:
>>I couldn't find -Xcompiler or -Wc in the manual...
>  
> In 1.5.6's manual, it is documented in the "Compile mode" node (in
> "Invoking libtool").

Oh yes, thanks.  And in CVS libtool... I should have used the .texi file to
start with instead of trying to look it up using the info browser :-/

>>But there is also -Xcompiler for these cases.  Remember that libtool is
>>supposed to hide platform specific concerns, and if we started adding
>>specific support for particular compiler switches, libtool would soon
>>have no advantage over using the compiler directly for developers who
>>want to provide a package that compiles on several hosts.
> 
> Well, libtool already accumulates knowledge about various compilers,
> linkers and so on.  So adding such switches can be seen as teaching it
> about useful things it should be aware of.  ;-) 

It does, but the interface to the user doesn't change depending on the
host machine.  -Xcompiler and -Xlinker are there so that if we find a
missing abstraction, libtool users can continue to work while we figure
out how to incorporate a clean abstraction into the user interface.

>>If you can find a higher level abstraction that can be implemented for
>>all platforms that libtool supports, along with a patch for the 
>>platforms
>>you have access to, then we can probably accept that.  E.g: libtool 
>>- --abi=32,
>>or libtool --threaded...
> 
> 
> There need to be some sort of an abstraction.  I'm not sure, however,
> whether it's up to Libtool to do this or not (because there may be a lot
> more options than just those we're talking about).  I currently use an
> Autoconf macro that determines the C++ compiler vendor, and then a set
> of macros such as `AC_CXX_CXXFLAGS_STD_LANG' and
> `AC_CXX_LDFLAGS_STD_LANG', etc. that augment my `CXXFLAGS', `CPPFLAGS'
> and `LDFLAGS' with the particular switches that are needed to turn on
> standard C++ features with this compiler.  I believe this approach is
> simpler than augmenting Libtool with a plethora of very specific
> options.  But anyway, this "knowledge base" about specific compiler
> tricks has to be kept somewhere in such a way that people wouldn't have
> to worry any longer about those specificities.

Libtool is designed to work without automake and autoconf too.  So,
although your solution works well for you, it will be of benefit to the
most people if we can move it into libtool itself along with all the
other compiler specific knowledge that is stored there.

You are right that there are a plethora of compilation options, and
we strive to boil those down to a uniform interface, so that libtool
users don't need to learn them... they should be able to tell libtool
what they want to do, and *it* figures out which options to pass to
the compiler and linker.  Of course, we only have the commonly used
compilation features abstracted away at the moment, and there will always
be room to move features up from the compiler driver level to the
libtool interface...

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature