automake
[Top][All Lists]
Advanced

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

Re: _la_SOURCES Makro does not link all defined sources...


From: Ralf Wildenhues
Subject: Re: _la_SOURCES Makro does not link all defined sources...
Date: Wed, 12 Oct 2005 13:19:02 +0200
User-agent: Mutt/1.5.11

Hi Steve,

* Steve wrote on Wed, Oct 12, 2005 at 12:36:47PM CEST:
> Ralf Wildenhues wrote:
> >
> >Hmm.  I'm not quite sure why you list all the objects in *_LIBADD
> >individually, rather than doing
> > libnsHTMLValidator_la_SOURCES = \
> > nsVector.cpp \
> > nsHTMLValidator.cpp \
> > alloc.cpp \
> > ...
> >(or whatever the source for alloc.o etc. are called)
> >
> Because I have a subdirectory in my src folder, which is called tidy,
> where alloc.c and all tidy sources are located.  This one is buildet via:
> -------------
> noinst_LIBRARIES = libtidy.a
> libtidy_a_SOURCES = alloc.c \
>                               ...
> ----------------
> Is there a better way to link my shared lib against this object files,
> or perhaps right against libtidy.a?

Yep.  In fact, unless there are compelling reasons to do otherwise, you
should make libtidy a "libtool convenience archive" (please read up on
it in the Libtool docs and this email[1] to understand the implications
of the change, or ask).  That can be achieved by using 

  noinst_LTLIBRARIES = libtidy.la
  
instead (and using libtidy_la_SOURCES then, of course).

Then you link the complete libtidy into libnsHTMLValidator.la by using
  libnsHTMLValidator_la_LIBADD = tidy/libtidy.la

and be done with this.  This will also solve your PIC problems (which
you may or may not have encountered yet; if not, try building on a 64bit
system for a change :).

> >The other thing I notice is that I would always write `alloc.o' instead
> >of `./alloc.o'.  I haven't tested now if it applies in this case, but in
> >general some `make' implementations do not treat both the same.
> >
> Perhaps the better way is to do it with $(top_srcdir) so i think
> its a sure method so automake does this for me :)

Naah, see above.

> >Oh, another thing: if the thingy is going to be a module to be dlopen'ed
> >by firefox (is that correct?), 
> >
> Yes thats correct. It should be integrated via XPCom as a firefox
> extension plugin.
> 
> >I'd guess it should not end up in
> >$libdir, so the prefix should not be lib_LTLIBRARIES, 
> >
> I think this doesnt matter because I have a shell script which
> construct me the correct library name in the correct directory
> structure...

Well, wrt. the rpath entry/entries in the installed
libnsHTMLValidator.so, this _will_ matter, believe me.

> >Nope, right.  Can you make sure the symbol makes it into the .so file
> >(use `nm | grep _ZN8nsVectorI8nsCOMPtrI17nsIValidatorErrorEEC1Ev' for
> >example)?
> >
> When i call this command it says me that the symbol appears in the
> .so lib. The output is exactly this:
> ---
> U _ZN8nsVectorI8nsCOMPtrI17nsIValidatorErrorEEC1Ev
> ---
> But i dont know for what the symbol U stands for...

Undefined.  So the symbol is not defined in that shared library (`T' is
for non-static defined code aka `text', others are documented in `man
nm' as well).

So, we're back to the prize question: which entity defines
| nsVector<nsCOMPtr<nsIValidatorError> >::nsVector()

?  Unfortunately, I am blissfully ignorant of mozilla source, so I can
only guess randomly: you are missing some template instantiation?

In case your module needs symbols by the program that dlopens it, the
program should have been linked with `-export-dynamic' (or its
non-libtool equivalent).  Just FYI, nothing you're likely to need to
worry about for this issue.

> > Could you show the way the modules is linked: `libtool
> >--mode=link' line plus all its output?
> >
> The output is:
> -------------------
> /bin/sh ../libtool --tag=CXX --mode=link g++  -g -O2  -L 
> /usr/lib/gecko-sdk/lib -L /usr/lib/gecko-sdk/bin -o 
> libnsHTMLValidator.la -rpath /usr/local/lib  nsHTMLValidator.lo 
> nsVector.lo tidy/access.o tidy/alloc.o tidy/attrs.o tidy/config.o 
> tidy/istack.o tidy/pprint.o tidy/tidylib.o tidy/attrask.o tidy/buffio.o 
> tidy/entities.o tidy/lexer.o tidy/streamio.o tidy/tmbstr.o 
> tidy/attrdict.o tidy/charsets.o tidy/fileio.o tidy/localize.o 
> tidy/tagask.o tidy/utf8.o tidy/attrget.o tidy/clean.o tidy/iconvtc.o 
> tidy/parser.o tidy/tags.o tidy/win32tc.o

AFAICS, that's the command line.  I always also would like to see what
executing this command line generates (output from `libtool', output
from `g++', whatever comes out on stdout and stderr).

> So it looks like nsVector is linked the same way as all other object
> files are linked against my lib.  Also i should say function calls to
> functions which are defined for example in alloc.o went well.  Only
> the function in nsVector.cpp are not correctly linked....

Cheers,
Ralf

[1] http://lists.gnu.org/archive/html/libtool/2005-08/msg00078.html




reply via email to

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