[Top][All Lists]
[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)