This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: LDFLAGS handling in V3


On Jul 27, 2005, Mark Mitchell <mark@codesourcery.com> wrote:

>    eval libtool --mode=link ... `libtool-ldflags $(LDFLAGS)`

eval is dangerous because it will evaluate other args twice.

What I had in mind was more like:

LTLDFLAGS = $(shell libtool-ldflags $(LDFLAGS))

> (Alexandre, I didn't want to use -XCClinker because the GCC version of
> libtool doesn't have that, but that's a detail.)

Yep.

> which should work OK, since GNU make will evaluate the shell command
> early.  But, libstdc++ hasn't yet gone over to GNU make; it's still
> assuming plain automake, I think.

I think all of GCC has adopted GNU make.  automake aims at portable
makefiles, but it won't stand in the way if you want to use less
portable constructs.

>    "LTLDFLAGS=`libtool-ldflags $(LDFLAGS)`"

> to EXTRA_TARGET_FLAGS.  Then, the sub-make files can just choose
> between LDFLAGS and LTLDFLAGS, depending on whether or not they're
> using libtool.  Does that sound like the right plan?

This will work for one recursion level, but not for two or more.  I'm
not sure how to overcome the problems of additional levels of
recursion with quotes in LDFLAGS.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]