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

[Steve]

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

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

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

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
>
>  
Thanks for your help...

Steve