bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Additional link flags for HP aCC and SGI CC


From: Gary V. Vaughan
Subject: Re: Additional link flags for HP aCC and SGI CC
Date: Tue, 24 Aug 2004 15:25:57 +0100
User-agent: Mozilla Thunderbird 0.7 (X11/20040615)

Salut Ludovic,

Ludovic Courtès wrote:
> Today, 2 hours, 29 minutes, 36 seconds ago, Gary V. Vaughan wrote:
>>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.

[[snip]]

> Ok.  I didn't know moving such higher-level features into Libtool was
> planned since there are currently mostly generic features.  I also
> thought this would go way beyond the goal of a "generic library support
> script".

Well, that's true too.  There is a fine line to walk here, and we need
to be careful not to clutter libtool's interface when say, simply passing
-Os through to the compiler and linker is a perfectly good solution.

> Libtool options like `--cxx-flags=std,local-template', `--multi-thread',
> `--abi=32' (although this one is very platform specific anyway since
> `--abi=mips2' wouldn't make much sense on IA32), or even things like
> `--warnings=2', `--optimization=3' and so on would be very cool.  For
> common options, another solution would be to let the user use GCC-like
> switches (eg. `-O2', `-Wall') which would then be converted into the
> target compiler switches.  What do you think?

I hadn't thought about it in those terms, and some of your examples are
still too low level.  However, --multi-thread is something we would
definitely like to have, and -Wall is an interesting option too.

The main barrier to providing a good interface to many of the features
we are obviously missing is our lack of support for multilibs.  I think
that if we do that right, abi support, and thread support would fall
out pretty much of their own accord.  Unfortunately, none of the libtool
developers use multilib, and I'm not aware of a libtool using project
that would need it (at least until I saw Bob's message about gcc multilib
builds just now).

If you'd like to help out with this (-Wall might be a good place to start),
and you are in a position to assign copyright of your patches to the FSF,
I for one would be delighted to help you out.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]