libtool-patches
[Top][All Lists]
Advanced

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

Re: Propagate $compiler_flags


From: Albert Chin
Subject: Re: Propagate $compiler_flags
Date: Fri, 3 Sep 2004 02:34:15 -0500
User-agent: Mutt/1.5.6i

On Thu, Sep 02, 2004 at 09:31:31PM -0500, Albert Chin wrote:
> On Fri, Sep 03, 2004 at 02:57:55AM +0100, Gary V.Vaughan wrote:
> > On 3 Sep 2004, at 02:28, Albert Chin wrote:
> > >Why don't we use $compiler_flags when using $LTCC?
> > 
> > Looking through the rest of ltmain.in, there are a number of other 
> > invocations of LTCC, and none of them use $compiler_flags.  It seems 
> > wrong to use them sometimes but not others.
> > 
> > $compiler_flags are collected from command line arguments for the 
> > current --tag, and are appropriate for that compiler (say f77), where 
> > LTCC is always the C compiler for building from internally generated C 
> > sources, where the fortran compiler_flags may not be appropriate.
> > 
> > Is the lack of compiler_flags causing you a problem?
> 
> If this patch is accepted, yes (passing non-recognized options to
> $compiler_flags):
>   http://lists.gnu.org/archive/html/libtool-patches/2004-09/msg00034.html
> 
> At the moment, building a 64-bit libtool on HP-UX means you have to
> CC="cc +DD64". The patch above makes it possible with CC=cc
> CFLAGS="+DD64" but then any time you use $LTCC, you must pass +DD64 to
> create 64-bit objects. I am hoping libtool doesn't have to recognize
> options like these (-64 and -mips[0-9] for IRIX, -xarch=*|-xtarget=*
> for Solaris, +DA* and +DD* for HP-UX, etc.).
> 
> One possibility is to save the initial $CFLAGS when creating libtool
> and use it when calling $LTCC.

I created LTCFLAGS, similar to LTCC, and that seems like a clean
solution. I'll submit a patch soon.

-- 
albert chin (address@hidden)




reply via email to

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