* 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
