On Thu, 2012-12-06 at 11:54 +0000, Gordon Sim wrote: > On 12/05/2012 08:44 PM, Alan Conway wrote: > > There is a serious problem with this patch. My build (on RHEL5 at trunk > > r1417511) fails with lots of these: > > > > g++: /usr/lib64/libqpidcommon.so: No such file or directory > > g++: /usr/lib64/libqpidtypes.so: No such file or directory > > > > > > It looksl like using -lqpidcommon on the link line tries to link with > > the library installed in /usr/lib, and fails to build if Qpid is not > > installed. > > > > It is most important that qpid's own libraries be specified via an > > explicit path, and not discovered by the linker, to ensure that a build > > actually links with its own libraries. > > > > I'm not sure what the proper way to do this is with libtool (curse you > > libtool!!!!) but I don't think we can leave it this way. > > I couldn't reproduce the problem on RHEL 5.8, using latest trunk. > Whether or not there were qpid libraries installed it seemed to pick up > the correct ones from the build for me). > > That said, we should probably be linking against the .la with libtool? > That seems to have been the approach previously which didn't cause these > problems. > > Attached is a patch that would do this. Are you able to test it on the > system that caused problems to ensure it does actually fix the problem? > It works for me on Fedora 17 and RHEL 5.8, but as I say I couldn't > reproduce the problem in the first place.
The patch works, I approve. Using full paths to the libs is much safer than letting the linker find them. I misspoke earlier - I actually saw this on RHEL 6.2. Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
