qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: First Qpid 0.6 Beta Release available for download and testing
Date Wed, 09 Dec 2009 15:37:22 GMT
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.
>>
>>    [aconway@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-subscribe@qpid.apache.org


Mime
View raw message