Re: Strange behaviour in libtool-1.5.20

[Ralf Wildenhues]

* Пухальский Юрий Андреевич wrote on Mon, Sep 05, 2005 at 05:16:38PM CEST:
> > * Пухальский Юрий Андреевич wrote on Fri, Sep 02, 2005 at 11:39:20AM CEST:
> > >
> > > I have then a Makefile.am like following:
> > > ----------------
> > > noinst_LTLIBRARIES=liba.la libb.la
> > >
> > > libb_la_SOURCES=b.c
> > >
> > > liba_la_SOURCES=a.c
> > > liba_la_LIBADD=libb.la
> > > liba_la_LDFLAGS=-o la.o
> > 
> > This setting of liba_la_LDFLAGS is wrong.  You may not set the output
> > name in LDFLAGS.  The output name is already given implicitly, by the
>
> We have a recognized option in libtool --mode=link:
> -o OUTPUT-FILE    create OUTPUT-FILE from the specified objects
> And later in help we read:
> If OUTPUT-FILE ends in `.lo' or `.o', then a reloadable object file
> is created, otherwise an executable program is created.
> I cannot think of any other place in Makefile.am to specify this flag.

Oh, libtool recognizes this option fine.  It's Automake that forbids you
to use it in *_LDFLAGS, because it adds a "-o liba.la" itself!

Just write the rule yourself, like this:

la_o_deps = a.lo b.lo
la.o: $(la_o_deps)
        $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
        --mode=link $(CC) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(la_o_deps)

(you might want to adjust variable naming a bit -- this is most
Automake-like I could think of)

> > variable name: it will be liba.la.
> I cannot set output file name in library name, because I then get:
> `liba.o' is not a standard libtool library name
> Makefile.am:1: did you mean `liba.la'?

You just can't use the full Automake machinery for this target.

> > The library liba.la will be a so-called convenience archive.  Since
> > libb.la is a convenience archive as well, and you have given it as
> > LIBADD for liba.la it will be subsumed in ("copied into") liba.la.
> > 
> > If you want a static or shared library instead, you need to remove the
> > noinst_ prefix.
>
> I should have started with it: I need a partially-linked object.  I
> need to make a module for vxworks. They don't accept but the result of
> "ld -r" as modules, so trying to get use of libtool's partial linking
> feature was a natural choice.

Ah, ok.  I don't know vxworks very well, but above rule should get you
on the right track.

> > > Resulting object file la.o contains a.o.
> > 
> > Well, the libtool object "la.o" will contain references to the PIC
> > object .libs/a.o and to the non-PIC object a.o.
> La.o will not be libtool object, it will be real object. I think we
> had a misunderstanding here, I hope I have cleared it before in this
> message:)

Yes, I think so.

> > I don't understand at all what you are really trying to achieve.
>
> Just a partial linking. I remember I had written about it some time
> ago.

Yes, I remember.  I actually have a couple of your mails still in the
list of things to "check if this works now, and work on it if not"..
(but that list is very long).

> Then I had to make a kernel module for Solaris, which is in fact
> partially linked object too, and I wondered whether I can specify
> additional linker flags to it (it turned out, that I cannot specify
> any, because partial linking is considered unportable). Now I just
> wonder what this feature is for:)))

Well, it's not too unportable, many systems have it in one way or
another.  It's just not very useful either, except to work around
command line length limits.  And for this, libtool also has -objectlist
as a counter-measure.

Does this help you?

Cheers,
Ralf