bug-libtool
[Top][All Lists]
Advanced

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

RE: Strange behaviour in libtool-1.5.20


From: Пухальский Юрий Андреевич
Subject: RE: Strange behaviour in libtool-1.5.20
Date: Mon, 5 Sep 2005 19:16:38 +0400

> Hi Yuri,
Hello, Ralf!

> * Пухальский Юрий Андреевич wrote on Fri, Sep 02, 2005 at 11:39:20AM CEST:
> >
> > I've encountered a strange behaviour on RedHat 9, with libtool 1.5.20
> > and gcc 3.4.3. I think, with previous libtool releases was the same
> > problem.  I have two files:
> *snip*
> > ----------------
> > 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.

> 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'?

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

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


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




reply via email to

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