Manuel Teira escribió:
After this, and a pair of minor changes I've sent to Andrew, regarding
previously committed changes, there's only one little glitch avoiding a
clean solaris build. I'm asking for your advise with this issue:
I need to explicitly provide a -lboost_system to link qpidd. I don't
know if it's related with some solaris linker bug or feature, but even
when I provide a LD_LIBRARY_PATH with the boost libraries location, it
seems unable to find it. This is what the linker dumps out when no
-lboost_system is provided:
CC -g -m64 -I/opt/dslap/contrib/include -mt -mt -o .libs/qpidd qpidd.o
-L/opt/dslap/contrib/lib -L/usr/lib/openais -L/usr/lib64/openais
./.libs/libqpidbroker.so
/export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so
./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem
-luuid -library=stlport4 -R/opt/dslap/contrib/lib
ld: warning: file ./.libs/libqpidcommon.so: linked to
/export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so:
attempted multiple inclusion of file
Undefined first referenced
symbol in file
const boost::system::error_category&boost::system::get_posix_category()
qpidd.o (symbol belongs to implicit dependency
/opt/dslap/contrib/lib/libboost_system.so)
const boost::system::error_category&boost::system::get_system_category()
qpidd.o (symbol belongs to implicit dependency
/opt/dslap/contrib/lib/libboost_system.so)
ld: fatal: Symbol referencing errors. No output written to .libs/qpidd
More info on this issue. It seems that the actual problem is that SunCC
tools refuse to resolve this kind of implicit dependencies. I've
isolated a little example, sure it can be minimized, as always:
$ cat A.h
#ifndef A_H
#define A_H
int A();
#endif
$cat A.cc
#include "A.h"
int A() {
return 10;
}
$cat B.h
#ifndef B_H
#define B_H
#include "A.h"
int B() { return A(); };
int C();
#endif
$cat B.cc
#include "B.h"
int C() { return 0; }
$ cat main.cc
#include "B.h"
int main(int argc, char **argv) {
B();
}
$cat Makefile
CXX = CC
LD = $(CXX) -G
%.o : %.cc
$(CXX) -c $<
test : libA.so libB.so main.o
$(CXX) -o test main.o -L. -lB
libA.so : A.o
$(LD) -o libA.so A.o
libB.so : B.o
$(LD) -o libB.so B.o -L. -lA
clean:
rm -rf *.so *.o test
This is more or less the same case than in the libboost_filesystem and
libboost_system issue. Some symbols defined in libboost_system.so have
inlined usage in the libboost_filesystem header, thus injecting
unresolved symbols of libboost_system in source code including headers
from libboost_system. To be more precise, this behaviour is seen in:
qpidd.cpp including boost/filesystem/path.hpp
boost/filesystem/path.hpp including boost/system/system_error.hpp
boost/system/system_error.hpp including boost/system/error_code.hpp
boost/system/error_code.hpp defining
BOOST_SYSTEM_DECL const error_category & get_system_category();
Compiling the previous example, using Sun CC:
$ make
CC -c A.cc
CC -G -o libA.so A.o
CC -c B.cc
CC -G -o libB.so B.o -L. -lA
CC -c main.cc
CC -o test main.o -L. -lB
Undefined first referenced
symbol in file
int A() main.o (symbol belongs to implicit
dependency ./libA.so)
ld: fatal: Symbol referencing errors. No output written to test
*** Error code 1
make: Fatal error: Command failed for target `test'
Whereas doing the same with GNU g++ on a Linux machine:
$ make CXX=g++ LD="g++ -shared"
g++ -c A.cc
g++ -shared -o libA.so A.o
g++ -c B.cc
g++ -shared -o libB.so B.o -L. -lA
g++ -c main.cc
g++ -o test main.o -L. -lB
Works fine, being the test executable dinamically linked against the two
libraries.
I don't know if these implicit dependencies should be tracked
automatically by the compiler (it seems to know where the dependency is
located, but refuses to link it). I think that adding boost_system to
the libraries needed by qpidd, regardless the compiler won't hurt. What
do you think?
Regards.
