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
