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: Ludovic Courtès
Subject: Re: Additional link flags for HP aCC and SGI CC
Date: Wed, 25 Aug 2004 15:32:03 +0200
User-agent: Mutt/1.5.4i [Guile enabled]

Salut,

Yesterday, 22 hours, 53 minutes, 20 seconds ago, Gary V. Vaughan wrote:
> 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.

I started to look at `libtool.m4' to get an idea of how things work by
looking eg. at how `lt_prog_compiler_static_*' are determined.  First, I
must say that I am very impressed by the number of supported systems.
However, I am surprised by some of the assumptions that are made
regarding the compiler used on a given OS platform while, for instance,
GCC may be available on most of them.  Instead, I used to determine the
compiler being used by checking for particular preprocessor macros
(eg. `__GNUC__', `__DECCXX', etc.).  Is there any reason for not doing
this?  Maybe such macros are not always documented or may be changing
over time?

Thanks,
Ludo'.




reply via email to

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