[Top][All Lists]

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

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

From: Steve
Subject: Re: _la_SOURCES Makro does not link all defined sources...
Date: Wed, 12 Oct 2005 12:36:47 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050921)

Hi Ralf,

Ralf Wildenhues wrote:

Hi Steve,

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?

but two things come to mind: First, the way you do it, you have to make
sure yourself, that alloc.o etc. are compiled with PIC flags.  To avoid
this, you could list `libtool objects' instead: "alloc.lo attrs.lo ..".

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

Both of these remarks are unlikely to be relevant to the issue you
experience, though.

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

but something more
appropriate (better look how other such modules are built); also, you
should use `-module' then.

Ok thanks for this Information. I will take a look around.

Nope, right.  Can you make sure the symbol makes it into the .so file
(use `nm | grep _ZN8nsVectorI8nsCOMPtrI17nsIValidatorErrorEEC1Ev' for

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

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

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


Thanks for your help...


reply via email to

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