Ok, so it's not actually using pkg-config to get the linker arguments (been in automake territory for too long). I find this in the build directory:
$ ack qpid-proton CMakeCache.txt 494:amqp_LIB_DEPENDS:STATIC=general;qpidtypes;general;qpidbroker;general;qpidcommon;general;qpid-proton;general;ssl;general;crypto;general;uuid;general;/home/davin/external/boost-1.55.0/lib/libboost_program_options.a; 551:qpidmessaging_LIB_DEPENDS:STATIC=general;qpidtypes;general;qpidclient;general;qpidcommon;general;/home/davin/external/boost-1.55.0/lib/libboost_program_options.a;general;qpid-proton;general;ssl;general;crypto;general;uuid; 893:PROTON_LDFLAGS:INTERNAL=-L/home/davin/external/proton-0.5/lib64;-lqpid-proton;-lssl;-lcrypto;-luuid 896:PROTON_LIBRARIES:INTERNAL=qpid-proton;ssl;crypto;uuid 907:PROTON_STATIC_LDFLAGS:INTERNAL=-Wl,-z,relro;-L/home/davin/external/proton-0.5/lib64;-lqpid-proton;-lssl;-lcrypto;-ldl;-lz;-lgssapi_krb5;-lkrb5;-lcom_err;-lk5crypto;-luuid 910:PROTON_STATIC_LIBRARIES:INTERNAL=qpid-proton;ssl;crypto;dl;z;gssapi_krb5;krb5;com_err;k5crypto;uuid 917:PROTON_libqpid-proton_INCLUDEDIR:INTERNAL= 918:PROTON_libqpid-proton_LIBDIR:INTERNAL= 919:PROTON_libqpid-proton_PREFIX:INTERNAL= 920:PROTON_libqpid-proton_VERSION:INTERNAL= Hope it helps. On Wed, Jan 15, 2014 at 10:10 AM, Shearer, Davin <[email protected]>wrote: > The HA section in the CMakeLists.txt file is straightforward. I suspect > that the issue isn't with the HA build itself, but with the flags of its > dependencies (correctly, proton is not listed). Around line 636, we see > this: > > target_link_libraries (ha > qpidtypes qpidcommon qpidbroker qpidmessaging > "${Boost_PROGRAM_OPTIONS_LIBRARY}") > > > If this operation uses the pkg-config files of the dependency qpid* > libraries, I'd say that's where you're going to find your problem. > Specifically that one or more of those libraries have the -lqpid-proton > -lssl -lcrypto in its pkg-config file, but is missing the > -L/path/to/libqpid-proton argument. If that is the case, the fix is to put > qpid-proton into the Requires line instead. What that will do is use > pkg-config to get the (correct) linker flags from the qpid-proton.pc. > > > On Wed, Jan 15, 2014 at 9:51 AM, Shearer, Davin <[email protected]>wrote: > >> Hi Gordon, >> >> I put my changes off into a separate branch, switched back to trunk and >> re-ran the build on the unmodified source and I've still got the same >> problem (HA trying to link proton without the -L argument). In my >> CMakeLists.txt in cpp/src, the include (amqp.make) line is at 649. I'm >> using commit git-svn-id: >> https://svn.apache.org/repos/asf/qpid/trunk@155836313f79535-47bb-0310-9956-ffa450edef68. >> >> I then tried (as you suggested) moving the include (amqp.make) line to >> somewhere above the HA stuff: >> >> $ git diff >> diff --git a/qpid/cpp/src/CMakeLists.txt b/qpid/cpp/src/CMakeLists.txt >> index c77b753..5939419 100644 >> --- a/qpid/cpp/src/CMakeLists.txt >> +++ b/qpid/cpp/src/CMakeLists.txt >> @@ -574,6 +574,9 @@ if (BUILD_ACL) >> ) >> endif (BUILD_ACL) >> >> +# Check for optional AMQP 1.0 support requirements >> +include (amqp.cmake) >> + >> set (ha_default ON) >> >> option(BUILD_HA "Build Active-Passive HA plugin" ${ha_default}) >> @@ -645,9 +648,6 @@ endif (BUILD_HA) >> # Check for optional RDMA support requirements >> include (rdma.cmake) >> >> -# Check for optional AMQP 1.0 support requirements >> -include (amqp.cmake) >> - >> # Check for syslog capabilities not present on all systems >> check_symbol_exists (LOG_AUTHPRIV "sys/syslog.h" HAVE_LOG_AUTHPRIV) >> check_symbol_exists (LOG_FTP "sys/syslog.h" HAVE_LOG_FTP) >> >> The good news is that the amqp.so module built fine (it has the proper -L >> argument), but the HA module _still_ fails to link (missing the -L >> argument). And you're suspicion about HA not needing proton (nor ssl nor >> crypto) is correct and should be removed from the HA build. BTW, if I >> remove them by hand (-lqpid-proton -lssl -lcrypto), the ha.so module is >> linked successfully. >> >> >> On Wed, Jan 15, 2014 at 4:47 AM, Gordon Sim <[email protected]> wrote: >> >>> On 01/14/2014 09:48 PM, Shearer, Davin wrote: >>> >>>> Thanks for the quick response (I love the responsiveness of this group). >>>> AFAIK, proton is good to go. This appears to be a problem with the qpid >>>> build scripts not using pkg-config correctly (or my insufficient >>>> cmake-fu?!). It looks to me like it's using pkg-config --libs-only-l, >>>> which does indeed emit: >>>> >>>> $ pkg-config --libs-only-l libqpid-proton >>>> -lqpid-proton -lssl -lcrypto -luuid >>>> >>>> Which is what we see in the linker invocation, when it should be using: >>>> >>>> $ pkg-config --libs libqpid-proton >>>> -L/home/davin/external/proton-5.0/lib64 -lqpid-proton -lssl -lcrypto >>>> -luuid >>>> >>> >>> My first question was why ha.so needed to link to proton at all... that >>> appears to be a result of changing the 1.0 support in the client from a >>> plugin to compiled in (the ha module links against the client). >>> >>> What seems to be missing in your case is the effect of the >>> link_directories(${PROTON_LIBRARY_DIRS}) in amqp.cmake. That sets the >>> path for the library where $PROTON_LIBRARIES is only the library itself. >>> >>> I always build against a non-standard location of proton, and it works >>> for me as checked in on fedora 17. Does a build without your modifications >>> for static libraries work? >>> >>> One thought is whether moving the include (amqp.cmake) in line 652 up >>> above the ha section would help (line 579 or earlier) would help? >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> -- >> Davin Shearer >> > > > -- > Davin Shearer > -- Davin Shearer Engineer 8830 Stanford Blvd, Suite 306 Columbia, MD 21045 443-741-4517
