libtool-patches
[Top][All Lists]
Advanced

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

Re: Fix cwrapper test failure with --disable-static.


From: Charles Wilson
Subject: Re: Fix cwrapper test failure with --disable-static.
Date: Wed, 10 Nov 2010 17:23:52 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

On 11/10/2010 4:07 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET:
>> Wouldn't a better fix be to change the link command to reference m.lo
>> instead of m.$OBJEXT ?
> 
> That would be an alternative, but it would mean that we (needlessly) use
> PIC code on systems where non-PIC is turned off by default (or
> --disable-static was used).

I thought that in those cases, the .lo file would redirect to the
regular, non-pic .o but I guess what actually happens is that you get
neither the .lo NOR the .libs/.o pic file, and you see only the non-pic .o.

> automake-generated code also compiles
> program sources without libtool, so the change was, to me, the canonical
> one.

Meh...only if the target is explicitly *.o   If it's .lo, then
$(LTCOMPILE) is used, and then libtool generates either or both of the
.o's itself, as determined by the system defaults and/or
--enable-{shared,static}.

> Is there a portability issue associated with it?

I don't think so. It was simply a stylistic question: we're testing
libtool, so...use libtool. :-)

--
Chuck



reply via email to

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