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

[Steve]

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 
>
>  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 :).
>  
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
> > structure...
> >    
>
> Well, wrt. the rpath entry/entries in the installed
> libnsHTMLValidator.so, 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
> > > 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?
>
>  
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 
> > 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).
>
>  
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 
libnsHTMLValidator.la -rpath /usr/local/lib  nsHTMLValidator.lo 
nsVector.lo nsHTMLValidatorModule.lo tidy/libtidy.la
rm -fr  .libs/libnsHTMLValidator.a .libs/libnsHTMLValidator.la 
.libs/libnsHTMLValidator.lai .libs/libnsHTMLValidator.so 
.libs/libnsHTMLValidator.so.0 .libs/libnsHTMLValidator.so.0.0.0
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/./libstdc++.so -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,libnsHTMLValidator.so.0 -o .libs/libnsHTMLValidator.so.0.0.0
(cd .libs && rm -f libnsHTMLValidator.so.0 && ln -s 
libnsHTMLValidator.so.0.0.0 libnsHTMLValidator.so.0)
(cd .libs && rm -f libnsHTMLValidator.so && ln -s 
libnsHTMLValidator.so.0.0.0 libnsHTMLValidator.so)
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
creating libnsHTMLValidator.la
(cd .libs && rm -f libnsHTMLValidator.la && ln -s 
../libnsHTMLValidator.la libnsHTMLValidator.la)
----------------------------------
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....
> >    
>
> Cheers,
> Ralf
>
> [1] http://lists.gnu.org/archive/html/libtool/2005-08/msg00078.html
>
>  
Thank you,

Steve