On 12/07/2009 11:04 AM, Andrew Stitcher wrote:
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.
My cmake build does not have those flags in the link line for cluster.so:
/usr/bin/ccache /usr/bin/distcc g++ -fPIC -g -O -shared
-Wl,-soname,cluster.so -o cluster.so
CMakeFiles/cluster.dir/qpid/cluster/Quorum_cman.o
CMakeFiles/cluster.dir/qpid/cluster/Cluster.o
CMakeFiles/cluster.dir/qpid/cluster/Decoder.o
CMakeFiles/cluster.dir/qpid/cluster/ClusterMap.o
CMakeFiles/cluster.dir/qpid/cluster/ClusterPlugin.o
CMakeFiles/cluster.dir/qpid/cluster/Connection.o
CMakeFiles/cluster.dir/qpid/cluster/ConnectionCodec.o
CMakeFiles/cluster.dir/qpid/cluster/Cpg.o
CMakeFiles/cluster.dir/qpid/cluster/UpdateClient.o
CMakeFiles/cluster.dir/qpid/cluster/RetractClient.o
CMakeFiles/cluster.dir/qpid/cluster/ErrorCheck.o
CMakeFiles/cluster.dir/qpid/cluster/Event.o
CMakeFiles/cluster.dir/qpid/cluster/EventFrame.o
CMakeFiles/cluster.dir/qpid/cluster/ExpiryPolicy.o
CMakeFiles/cluster.dir/qpid/cluster/FailoverExchange.o
CMakeFiles/cluster.dir/qpid/cluster/Multicaster.o
CMakeFiles/cluster.dir/qpid/cluster/OutputInterceptor.o
CMakeFiles/cluster.dir/qpid/cluster/PollerDispatch.o
CMakeFiles/cluster.dir/qpid/cluster/InitialStatusMap.o
CMakeFiles/cluster.dir/qpid/cluster/MemberSet.o
CMakeFiles/cluster.dir/qpid/cluster/StoreStatus.o -lcpg -lcman
libqpidbroker.so.0.6 libqpidclient.so.0.6 -lboost_filesystem-mt
libqpidcommon.so.0.6 -lboost_program_options-mt -lboost_filesystem-mt -luuid
-ldl -lrt -lsasl2 -Wl,-rpath,/home/aconway/qpid/qpid/cmake/src
I don't know why those flags aren't present, maybe something wrong with the
CMAKE_COMPILER_IS_GNUCXX that's causing it to fail on my box? How can I debug
what cmake is doing here?
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()
Yep, they're undefined for me as well but not causing a compile error due to the
missing flags. I'm still not clear on what the solution is here:
- drop the --no-undefined-flags
- explicitly link with boost system if present
We could drop the --no-undefined flag for cluster.so only as a workaround if
linking with boost system is tricky.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
