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

[Ralf Wildenhues]

* Charles Wilson wrote on Wed, Nov 10, 2010 at 11:23:52PM CET:
> 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.

I'm not sure I follow.

If you pass --disable-static, then a command to build an .lo file will
build that, plus the .libs/.o PIC file.  There just will not be an .o
file outside of the .libs directory.

We could of course do 'test -f m.$OBJEXT || o=$objdir/m.$OBJEXT'
or something like that, but I didn't really want to make the code
more complicated than necessary.

> > 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}.

Sure.  But automake will let the target explicitly be *.$(OBJEXT) for
objects to be linked into programs.

> > 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. :-)

Sure.  But we are allowed to test it in the same way that it is commonly
used.  ;-)

Cheers,
Ralf