On Wed, 2008-08-20 at 14:10 +0200, Manuel Teira wrote:
> 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.
>
I don't see a problem with this, but we should make it clear that it's
required by Solaris - at least in a comment if not in a makefile
conditional - otherwise some day someone using linux will say "hey
that's not required, it's linked implicitly" and take it out again.
Cheers,
Alan.
