On Mon, 2009-12-07 at 10:28 -0500, Alan Conway wrote:
> On 12/04/2009 12:20 PM, Andrew Stitcher wrote:
> > On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote:
> >> ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
> >>
> >>> Cmake build is mostly fine - however the clustering module doesn't build
> >>> due to a complication of recent versions of boost.
> >>
> >> The cluster& cluster test build& pass for me on f11 with
> >> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I
> >> can
> >> log into where you see the problem?
> >
> > In response - I don't understand how you can be building this! The
> > StoreStatus.o has references to symbols that are only in libboost_system
> > but it's not directly linked. However having said this I also can't
> > understand why the autotools build does work by the same token - it's a
> > bit of a mystery!
> >
>
> ldd shows that in my build cluster.so is indeed linked with boost_system-mt.
>
> [acon...@rolf cmake]$ ldd src/cluster.so | grep boost
> libboost_filesystem-mt.so.4 => /usr/lib64/libboost_filesystem-mt.so.4
> (0x00007f1d97f67000)
> libboost_program_options-mt.so.4 =>
> /usr/lib64/libboost_program_options-mt.so.4 (0x00007f1d978ac000)
> libboost_system-mt.so.4 => /usr/lib64/libboost_system-mt.so.4
> (0x00007f1d95f44000)
>
> Also note that libcommon uses boost::filesystem and links without problems,
> although perhaps StoreStatus is using different symbols. What missing symbols
> are you seeing?
Ok, I haven't explained in enough detail:
libqpidcommon isn't a problem because by default shared objects are
allowed to have unresolved symbols at link time on the Unix systems I
know - if they weren't resolved at the run time load you'd get an error
- generally sigkill to the process.
ldd doesn't tell you what you need to know here as it gives the
transitive linkage - ie in this case libboost_system is loaded because
libboost_filesystem requires it. To get the actual (non transitive)
requires of an object you need to use objdump -p.
When we build plugin modules for qpid we tell the linker to give an
error if it finds unresolved symbols when linking against the non
transitive requirements (--no-undefined to the linker -Wl,--no-undefined
to the compiler). It's possible that libtool adds another option to make
it check the symbols transitively, which would explain why the autotools
build works, but I can't see why your cmake build could be different
from mine.
The symbols that are unresolved in all of the shared objects that use
boost_filesystem due to inline expansions of things from it are:
U boost::system::get_system_category()
U boost::system::get_generic_category()
Regards
Andrew
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
