qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject another 0.20 request (was Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit linking)
Date Thu, 06 Dec 2012 16:59:07 GMT
On 12/06/2012 03:18 PM, Alan Conway wrote:
> 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.

I couldn't reproduce on RHEL 6.2 either... however I have committed to 
trunk (see r1418000) as I think we are agreed it is a safer change anyway.

Justin, can I request permission to make that change to 0.20 also? 
Simply because we backported the change that caused this error in Alan's 
case and he reports this fixes it.

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

View raw message