qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking
Date Thu, 06 Dec 2012 15:18:29 GMT
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. 


To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message