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