You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2012/12/05 21:44:43 UTC
r1415137: QPID-3723: Applied patch from Fraser Adams for explicit
linking
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: another 0.20 request (was Re: r1415137: QPID-3723: Applied patch
from Fraser Adams for explicit linking)
Posted by Gordon Sim <gs...@redhat.com>.
On 12/06/2012 07:37 PM, Justin Ross wrote:
> On Thu, 6 Dec 2012, Gordon Sim wrote:
>
>> 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.
>
> Approved.
Thanks! Committed to branch now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: another 0.20 request (was Re: r1415137: QPID-3723: Applied patch
from Fraser Adams for explicit linking)
Posted by Justin Ross <jr...@redhat.com>.
On Thu, 6 Dec 2012, Gordon Sim wrote:
> 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.
Approved.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
another 0.20 request (was Re: r1415137: QPID-3723: Applied patch
from Fraser Adams for explicit linking)
Posted by Gordon Sim <gs...@redhat.com>.
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
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for
explicit linking
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2012-12-06 at 18:36 +0000, Fraser Adams wrote:
> Hi both,
> Thanks for this - and sorry for the problems it caused you Alan. I did
> this a while back for Qpid 0.12 'cause I'm running Ubuntu 11.10 (well
> Mint 12 really) and ended up tearing my hair out for a while.
>
> I'd sort of assumed that Qpid was mainly going to be targeted ad RHEL
> given the RH core team so had resigned myself to always having to hack
> and patch to get it up and running on Ubuntu and had submitted this more
> in hope than anything.
>
> It's the main reason I've stuck with 0.12 as my work on the Qpid Web UI
> hasn't left me much time to tinker with this stuff.
>
> I'm really pleased that this stuff is making it into main now, so thanks
> for that and sorry for the issues, I'm afraid that I know SFA about the
> magic of libtool/automake and all that I'm afraid I was winging it
> rather - it's a miracle it worked as well as it did :-)
>
No need to apologize, breaking things is an inevitable part of making
them better :) Your contributions are greatly appreciated.
I *really* hate libtool/automake. It's over-complicated and not at all
intuitive. I dream of the day we'll toss it and use cmake only (though I
may come to hate cmake after that...)
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit
linking
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi both,
Thanks for this - and sorry for the problems it caused you Alan. I did
this a while back for Qpid 0.12 'cause I'm running Ubuntu 11.10 (well
Mint 12 really) and ended up tearing my hair out for a while.
I'd sort of assumed that Qpid was mainly going to be targeted ad RHEL
given the RH core team so had resigned myself to always having to hack
and patch to get it up and running on Ubuntu and had submitted this more
in hope than anything.
It's the main reason I've stuck with 0.12 as my work on the Qpid Web UI
hasn't left me much time to tinker with this stuff.
I'm really pleased that this stuff is making it into main now, so thanks
for that and sorry for the issues, I'm afraid that I know SFA about the
magic of libtool/automake and all that I'm afraid I was winging it
rather - it's a miracle it worked as well as it did :-)
Cheers,
Frase.
On 06/12/12 15:18, 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.
>
> Cheers,
> Alan.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for
explicit linking
Posted by Alan Conway <ac...@redhat.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: r1415137: QPID-3723: Applied patch from Fraser Adams for explicit
linking
Posted by Gordon Sim <gs...@redhat.com>.
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.