[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 16:37:37 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050921)

Hi Ralf,

Ralf Wildenhues wrote:

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
instead (and using libtidy_la_SOURCES then, of course).

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

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 :).
Ok this is done and work great for me. Thanks...

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

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

Thats a reason. I will try to fix this...

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

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?

Hm i dont know exactly what do you mean with instantiation
heres a little piece of my code, which should describe it:
class nsHTMLValidator : public nsIValidator
   //all the following symbols are marked as undefined:
nsVector<nsCOMPtr<nsIValidatorError> > m_errorList; //Instantiation of a nsVector object
   nsVector<nsEmbedCString> m_sourceLines;
   nsVector<nsEmbedCString> m_errorStringList;

//and the nsVector itselfs is a template with template functions
//and of course a default constructor:
template <class T>
class nsVector{

No when the implementation of the template functions of nsVector are
defined in the same file as the Functions for the nsHTMLValidator all went well.
If not the evil undefined symbols occure :)

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

Ok heres the whole output:
make[3]: Leaving directory `/home/redwing/documents/programming/face/components/src/tidy' make[3]: Entering directory `/home/redwing/documents/programming/face/components/src' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c -o nsHTMLValidator.lo nsHTMLValidator.cpp g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsHTMLValidator.cpp -fPIC -DPIC -o .libs/nsHTMLValidator.o
In file included from nsHTMLValidator.cpp:4:
../include/nsHTMLValidator.h:46: Warnung: `class nsHTMLValidator' only defines
  a private destructor and has no friends
../include/nsHTMLValidator.h:46: Warnung: `class nsHTMLValidator' has virtual
  functions but non-virtual destructor
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsHTMLValidator.cpp -o nsHTMLValidator.o >/dev/null 2>&1 /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c -o nsVector.lo nsVector.cpp g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsVector.cpp -fPIC -DPIC -o .libs/nsVector.o g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsVector.cpp -o nsVector.o >/dev/null 2>&1 /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c -o nsHTMLValidatorModule.lo nsHTMLValidatorModule.cpp g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsHTMLValidatorModule.cpp -fPIC -DPIC -o .libs/nsHTMLValidatorModule.o
In file included from nsHTMLValidatorModule.cpp:5:
../include/nsHTMLValidator.h:46: Warnung: `class nsHTMLValidator' only defines
  a private destructor and has no friends
../include/nsHTMLValidator.h:46: Warnung: `class nsHTMLValidator' has virtual
  functions but non-virtual destructor
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/lib/gecko-sdk/include -DXPCOM_GLUE -Wall -g -O2 -c nsHTMLValidatorModule.cpp -o nsHTMLValidatorModule.o >/dev/null 2>&1 /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 nsHTMLValidatorModule.lo tidy/ rm -fr .libs/libnsHTMLValidator.a .libs/ .libs/libnsHTMLValidator.lai .libs/ .libs/ .libs/ g++ -shared -nostdlib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/crtbeginS.o .libs/nsHTMLValidator.o .libs/nsVector.o .libs/nsHTMLValidatorModule.o -Wl,--whole-archive tidy/.libs/libtidy.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/usr/lib/. -Wl,--rpath -Wl,/usr/lib/. -L/home/redwing/documents/programming/face/components/src -L/home/redwing/documents/programming/face/components/src/tidy -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../.. /usr/lib/./ -L/usr/i486-slackware-linux/bin -L/usr/i486-slackware-linux/lib -L/usr/lib/gcc-lib/i486-slackware-linux/../../../i486-slackware-linux/lib -L/usr/lib/gcc-lib/i486-slackware-linux/../.. -lm -lc -lgcc_s /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/crtendS.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../crtn.o -Wl,-soname -Wl, -o .libs/ (cd .libs && rm -f && ln -s (cd .libs && rm -f && ln -s
rm -fr .libs/libnsHTMLValidator.lax
mkdir .libs/libnsHTMLValidator.lax
rm -fr .libs/libnsHTMLValidator.lax/libtidy.a
mkdir .libs/libnsHTMLValidator.lax/libtidy.a
(cd .libs/libnsHTMLValidator.lax/libtidy.a && ar x /home/redwing/documents/programming/face/components/src/tidy/.libs/libtidy.a) ar cru .libs/libnsHTMLValidator.a nsHTMLValidator.o nsVector.o nsHTMLValidatorModule.o .libs/libnsHTMLValidator.lax/libtidy.a/access.o .libs/libnsHTMLValidator.lax/libtidy.a/attrdict.o .libs/libnsHTMLValidator.lax/libtidy.a/buffio.o .libs/libnsHTMLValidator.lax/libtidy.a/config.o .libs/libnsHTMLValidator.lax/libtidy.a/iconvtc.o .libs/libnsHTMLValidator.lax/libtidy.a/localize.o .libs/libnsHTMLValidator.lax/libtidy.a/streamio.o .libs/libnsHTMLValidator.lax/libtidy.a/tidylib.o .libs/libnsHTMLValidator.lax/libtidy.a/win32tc.o .libs/libnsHTMLValidator.lax/libtidy.a/alloc.o .libs/libnsHTMLValidator.lax/libtidy.a/attrget.o .libs/libnsHTMLValidator.lax/libtidy.a/charsets.o .libs/libnsHTMLValidator.lax/libtidy.a/entities.o .libs/libnsHTMLValidator.lax/libtidy.a/istack.o .libs/libnsHTMLValidator.lax/libtidy.a/parser.o .libs/libnsHTMLValidator.lax/libtidy.a/tagask.o .libs/libnsHTMLValidator.lax/libtidy.a/tmbstr.o .libs/libnsHTMLValidator.lax/libtidy.a/attrask.o .libs/libnsHTMLValidator.lax/libtidy.a/attrs.o .libs/libnsHTMLValidator.lax/libtidy.a/clean.o .libs/libnsHTMLValidator.lax/libtidy.a/fileio.o .libs/libnsHTMLValidator.lax/libtidy.a/lexer.o .libs/libnsHTMLValidator.lax/libtidy.a/pprint.o .libs/libnsHTMLValidator.lax/libtidy.a/tags.o .libs/libnsHTMLValidator.lax/libtidy.a/utf8.o
ranlib .libs/libnsHTMLValidator.a
rm -fr .libs/libnsHTMLValidator.lax
(cd .libs && rm -f && ln -s ../
Hope you can read out some more information....

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



Thank you,


reply via email to

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