You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2007/04/30 14:18:21 UTC
[C++] Build
Hey C++ fokes,
I've been following the README but I've hit a sumbling block in
building the C++ broker
to summerize steps to this points
Building on Dual Core Xeon under Fedora 6.
Installed updates apr etc via yum.
and used the autotools install script to download tools to ~/qpid-tools.
then
[qpid@wglaibb3pjr2j cpp]$ ./bootstrap
docs/api/Makefile.am:9: wildcard $(top_srcdir: non-POSIX variable name
docs/api/Makefile.am:9: (probably a GNU make extension)
Is this ok?
and ./configure was quite happy
but make gets upset about the file format of /usr/lib/libapr-1.so ..
this is a sym-link to libapr-1.so.0.2.7
I'm a bit rusty on the building of C++, Linux apps.
Any thoughts? Do you need more info?
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crti.o
/usr/lib/gcc/x
86_64-redhat-linux/4.1.1/crtbeginS.o .libs/APRAcceptor.o
.libs/APRBase.o .libs/APRPool.o .libs/APRS
ocket.o .libs/LFProcessor.o .libs/LFSessionContext.o .libs/Socket.o
.libs/Thread.o .libs/AMQBody.o .
libs/AMQContentBody.o .libs/AMQFrame.o .libs/AMQHeaderBody.o
.libs/AMQHeartbeatBody.o .libs/AMQMetho
dBody.o .libs/BasicHeaderProperties.o .libs/BodyHandler.o
.libs/Buffer.o .libs/FieldTable.o .libs/Fr
amingContent.o .libs/InitiationHandler.o .libs/ProtocolInitiation.o
.libs/ProtocolVersion.o .libs/Pr
otocolVersionException.o .libs/Value.o .libs/AMQP_ClientProxy.o
.libs/AMQP_MethodVersionMap.o .libs/
AMQP_ServerProxy.o .libs/Exception.o .libs/ExceptionHolder.o
.libs/QpidError.o .libs/CommonOptions.o
.libs/Runnable.o .libs/Time.o /usr/lib/libapr-1.so -luuid -lcrypt
-lpthread -ldl -lrt -lboost_prog
ram_options -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../
../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/x86_64-redhat-
linux/4.1.1/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crtn.o
-Wl,-soname -
Wl,libqpidcommon.so.0 -o .libs/libqpidcommon.so.0.1.0
/usr/lib/libapr-1.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libqpidcommon.la] Error 1
make[3]: Leaving directory `/qpid/home/qpid/JPMC/M2/qpid/cpp/lib/common'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/qpid/home/qpid/JPMC/M2/qpid/cpp/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/qpid/home/qpid/JPMC/M2/qpid/cpp'
make: *** [all] Error 2
--
Martin Ritchie
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
On 02/05/07, Alan Conway <ac...@redhat.com> wrote:
> On Wed, 2007-05-02 at 12:35 +0100, Martin Ritchie wrote:
> > Ok found the problem.
> >
> > our box didn't have an ipv4 lookup for localhost in /etc/hosts
> >
> > The python script kinda gave it away by saying 'Name or service not known'
> >
> > It wouldn't connect to the java broker either but 127.0.0.1 would
> > connect to the java broker (though the python takes the -b host value
> > as the vhost value aswell) this led us to /etc/hosts which only had
> > the ipv6 value for localhost.
> >
> > Thanks for all your help getting to the bottom of this one.
> >
> > I wonder where the C++ was listening?
>
> Could you connect to the C++ broker with 127.0.0.1? I'm not much up on
> ipv6 config etc. do you think there's something more the broker needs to
> do to play nice with ipv6?
>
> Cheers,
> Alan.
I didn't try and specify the ip to connect to with python -> C++. I
made the python -> java work and it then just worked with python ->
C++.
If I get some spare time on the box then I'll try and remove the ipv4
localhost entry in hosts and see if we can specify it by ip.
However if virtual hosts are implemented on C++ then it is likely it
won't work. The java broker refused the connection as vhost 127.0.0.1
doesn't exist. In the java the vhosts are arbitrary strings so there
is no correlation between '127.0.0.1' and 'localhost'.
--
Martin Ritchie
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2007-05-02 at 12:35 +0100, Martin Ritchie wrote:
> Ok found the problem.
>
> our box didn't have an ipv4 lookup for localhost in /etc/hosts
>
> The python script kinda gave it away by saying 'Name or service not known'
>
> It wouldn't connect to the java broker either but 127.0.0.1 would
> connect to the java broker (though the python takes the -b host value
> as the vhost value aswell) this led us to /etc/hosts which only had
> the ipv6 value for localhost.
>
> Thanks for all your help getting to the bottom of this one.
>
> I wonder where the C++ was listening?
Could you connect to the C++ broker with 127.0.0.1? I'm not much up on
ipv6 config etc. do you think there's something more the broker needs to
do to play nice with ipv6?
Cheers,
Alan.
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
Alan,
yum installed apr apr-devel boost boost-devel to get the i386 versions.
Then Installed the i386 RPMs.
Ran
/usr/sbin/qpidd -t
Get a waiting qpidd as shown by pstack at the bottom of the email.
All looks well
But same as with 64bit version.
- Can't telnet locahost 5672
- Can't run python tests. fail to connect.
Just to be sure there isn't a networking related problem I rebuilt the
Java broker and ,,,,
Ok found the problem.
our box didn't have an ipv4 lookup for localhost in /etc/hosts
The python script kinda gave it away by saying 'Name or service not known'
It wouldn't connect to the java broker either but 127.0.0.1 would
connect to the java broker (though the python takes the -b host value
as the vhost value aswell) this led us to /etc/hosts which only had
the ipv6 value for localhost.
Thanks for all your help getting to the bottom of this one.
I wonder where the C++ was listening?
On 02/05/07, Martin Ritchie <ri...@apache.org> wrote:
> Thanks Alan,
> I'll check them out later today.
>
> On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> > I thought I had but clearly I goofed. They're there now:
> > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.i386.rpm
> > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.i386.rpm
> >
> > On Tue, 2007-05-01 at 17:12 +0100, Martin Ritchie wrote:
> > > Just to be clear.
> > >
> > > Did you put the 32bit rpms up in the same location as the 64bit ones?
> > >
> > > Thanks
> > >
> > > On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> > > > Hi,
> > > >
> > > > http://rhm.et.redhat.com/download/
> > > > Did you put just the src rpms up?
> > > >
> > > > On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> > > > > On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> > > > > > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > > > > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > > > > > I've been working on the M2 branch also and haven't seen the problem.
> > > > > > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > > > > > >
> > > > > > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > > > > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > > > > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Alan.
> > > > > > >
> > > > > >
> > > > > > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > > > > > is the same. I must have some incompatible item installed. Do you have
> > > > > > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> > > > > >
> > > > > > Cheers
> > > > >
> > > > > I just put x86 RPMs up in the same location.
> > > > >
> > > > > I'm a bit worried about what you're seeing, I'd like to pin it down. Let
> > > > > me know if things work OK on 32 bit, and I'll think about how to get
> > > > > some more info out of your stalled daemon. The ptrace you have looks
> > > > > normal for a qpidd waiting for connections.
> > > > >
> > > > > Cheers,
> > > > > Alan.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Martin Ritchie
> > > >
> > >
> > >
> >
> >
>
>
> --
> Martin Ritchie
>
--
Martin Ritchie
Thread 7 (Thread 4158659472 (LWP 19576)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6a42c in pthread_cond_timedwait@@GLIBC_2.3.2 ()
#2 0xf7e8e799 in apr_thread_cond_timedwait () from /usr/lib/libapr-1.so.0
#3 0xf7f96430 in qpid::broker::AutoDelete::run ()
#4 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#5 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#6 0xf7e663db in start_thread () from /lib/libpthread.so.0
#7 0x43c9806e in clone () from /lib/libc.so.6
Thread 6 (Thread 4148169616 (LWP 19577)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x43c986e6 in __epoll_wait_nocancel () from /lib/libc.so.6
#2 0xf7e957f1 in apr_pollset_poll () from /usr/lib/libapr-1.so.0
#3 0xf7f04f12 in qpid::sys::LFProcessor::poll ()
#4 0xf7f04f48 in qpid::sys::LFProcessor::getNextEvent ()
#5 0xf7f05698 in qpid::sys::LFProcessor::run ()
#6 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#7 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#8 0xf7e663db in start_thread () from /lib/libpthread.so.0
#9 0x43c9806e in clone () from /lib/libc.so.6
Thread 5 (Thread 4137679760 (LWP 19578)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6c98e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2 0xf7e68820 in _L_mutex_lock_776 () from /lib/libpthread.so.0
#3 0xf7e686f1 in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0xf7e8d2e0 in apr_thread_mutex_lock () from /usr/lib/libapr-1.so.0
#5 0xf7f0566b in qpid::sys::LFProcessor::run ()
#6 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#7 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#8 0xf7e663db in start_thread () from /lib/libpthread.so.0
#9 0x43c9806e in clone () from /lib/libc.so.6
Thread 4 (Thread 4127189904 (LWP 19579)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6c98e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2 0xf7e68820 in _L_mutex_lock_776 () from /lib/libpthread.so.0
#3 0xf7e686f1 in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0xf7e8d2e0 in apr_thread_mutex_lock () from /usr/lib/libapr-1.so.0
#5 0xf7f0566b in qpid::sys::LFProcessor::run ()
#6 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#7 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#8 0xf7e663db in start_thread () from /lib/libpthread.so.0
#9 0x43c9806e in clone () from /lib/libc.so.6
Thread 3 (Thread 4116700048 (LWP 19580)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6c98e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2 0xf7e68820 in _L_mutex_lock_776 () from /lib/libpthread.so.0
#3 0xf7e686f1 in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0xf7e8d2e0 in apr_thread_mutex_lock () from /usr/lib/libapr-1.so.0
#5 0xf7f0566b in qpid::sys::LFProcessor::run ()
#6 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#7 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#8 0xf7e663db in start_thread () from /lib/libpthread.so.0
#9 0x43c9806e in clone () from /lib/libc.so.6
Thread 2 (Thread 4106210192 (LWP 19581)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6c98e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2 0xf7e68820 in _L_mutex_lock_776 () from /lib/libpthread.so.0
#3 0xf7e686f1 in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0xf7e8d2e0 in apr_thread_mutex_lock () from /usr/lib/libapr-1.so.0
#5 0xf7f0566b in qpid::sys::LFProcessor::run ()
#6 0xf7f08ab4 in qpid::sys::Thread::runRunnable ()
#7 0xf7e99e06 in apr_threadkey_private_create () from /usr/lib/libapr-1.so.0
#8 0xf7e663db in start_thread () from /lib/libpthread.so.0
#9 0x43c9806e in clone () from /lib/libc.so.6
Thread 1 (Thread 4158662352 (LWP 19575)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xf7e6cf88 in accept () from /lib/libpthread.so.0
#2 0xf7e9237d in apr_socket_accept () from /usr/lib/libapr-1.so.0
#3 0xf7f03264 in qpid::sys::APRAcceptor::run ()
#4 0xf7f981ab in qpid::broker::Broker::run ()
#5 0x080504f4 in std::runtime_error::what ()
#6 0x43be0f2c in __libc_start_main () from /lib/libc.so.6
#7 0x0804fec1 in std::runtime_error::what ()
#0 0xffffe410 in __kernel_vsyscall ()
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
Thanks Alan,
I'll check them out later today.
On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> I thought I had but clearly I goofed. They're there now:
> http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.i386.rpm
> http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.i386.rpm
>
> On Tue, 2007-05-01 at 17:12 +0100, Martin Ritchie wrote:
> > Just to be clear.
> >
> > Did you put the 32bit rpms up in the same location as the 64bit ones?
> >
> > Thanks
> >
> > On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> > > Hi,
> > >
> > > http://rhm.et.redhat.com/download/
> > > Did you put just the src rpms up?
> > >
> > > On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> > > > On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> > > > > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > > > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > > > > I've been working on the M2 branch also and haven't seen the problem.
> > > > > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > > > > >
> > > > > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > > > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > > > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > > > > >
> > > > > > Cheers,
> > > > > > Alan.
> > > > > >
> > > > >
> > > > > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > > > > is the same. I must have some incompatible item installed. Do you have
> > > > > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> > > > >
> > > > > Cheers
> > > >
> > > > I just put x86 RPMs up in the same location.
> > > >
> > > > I'm a bit worried about what you're seeing, I'd like to pin it down. Let
> > > > me know if things work OK on 32 bit, and I'll think about how to get
> > > > some more info out of your stalled daemon. The ptrace you have looks
> > > > normal for a qpidd waiting for connections.
> > > >
> > > > Cheers,
> > > > Alan.
> > > >
> > > >
> > >
> > >
> > > --
> > > Martin Ritchie
> > >
> >
> >
>
>
--
Martin Ritchie
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
I thought I had but clearly I goofed. They're there now:
http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.i386.rpm
http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.i386.rpm
On Tue, 2007-05-01 at 17:12 +0100, Martin Ritchie wrote:
> Just to be clear.
>
> Did you put the 32bit rpms up in the same location as the 64bit ones?
>
> Thanks
>
> On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> > Hi,
> >
> > http://rhm.et.redhat.com/download/
> > Did you put just the src rpms up?
> >
> > On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> > > On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> > > > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > > > I've been working on the M2 branch also and haven't seen the problem.
> > > > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > > > >
> > > > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > > > >
> > > > > Cheers,
> > > > > Alan.
> > > > >
> > > >
> > > > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > > > is the same. I must have some incompatible item installed. Do you have
> > > > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> > > >
> > > > Cheers
> > >
> > > I just put x86 RPMs up in the same location.
> > >
> > > I'm a bit worried about what you're seeing, I'd like to pin it down. Let
> > > me know if things work OK on 32 bit, and I'll think about how to get
> > > some more info out of your stalled daemon. The ptrace you have looks
> > > normal for a qpidd waiting for connections.
> > >
> > > Cheers,
> > > Alan.
> > >
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>
>
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
Just to be clear.
Did you put the 32bit rpms up in the same location as the 64bit ones?
Thanks
On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> Hi,
>
> http://rhm.et.redhat.com/download/
> Did you put just the src rpms up?
>
> On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> > On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> > > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > > I've been working on the M2 branch also and haven't seen the problem.
> > > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > > >
> > > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > > >
> > > > Cheers,
> > > > Alan.
> > > >
> > >
> > > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > > is the same. I must have some incompatible item installed. Do you have
> > > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> > >
> > > Cheers
> >
> > I just put x86 RPMs up in the same location.
> >
> > I'm a bit worried about what you're seeing, I'd like to pin it down. Let
> > me know if things work OK on 32 bit, and I'll think about how to get
> > some more info out of your stalled daemon. The ptrace you have looks
> > normal for a qpidd waiting for connections.
> >
> > Cheers,
> > Alan.
> >
> >
>
>
> --
> Martin Ritchie
>
--
Martin Ritchie
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
Hi,
http://rhm.et.redhat.com/download/
Did you put just the src rpms up?
On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > I've been working on the M2 branch also and haven't seen the problem.
> > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > >
> > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > >
> > > Cheers,
> > > Alan.
> > >
> >
> > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > is the same. I must have some incompatible item installed. Do you have
> > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> >
> > Cheers
>
> I just put x86 RPMs up in the same location.
>
> I'm a bit worried about what you're seeing, I'd like to pin it down. Let
> me know if things work OK on 32 bit, and I'll think about how to get
> some more info out of your stalled daemon. The ptrace you have looks
> normal for a qpidd waiting for connections.
>
> Cheers,
> Alan.
>
>
--
Martin Ritchie
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2007-05-01 at 07:56 +0100, Martin Ritchie wrote:
> On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > I've been working on the M2 branch also and haven't seen the problem.
> > > Soon as I finish my current commit I'll make an RPM for you to try.
> >
> > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> >
> > Cheers,
> > Alan.
> >
>
> Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> is the same. I must have some incompatible item installed. Do you have
> 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
>
> Cheers
I just put x86 RPMs up in the same location.
I'm a bit worried about what you're seeing, I'd like to pin it down. Let
me know if things work OK on 32 bit, and I'll think about how to get
some more info out of your stalled daemon. The ptrace you have looks
normal for a qpidd waiting for connections.
Cheers,
Alan.
Re: [C++] Build
Posted by John O'Hara <jo...@gmail.com>.
Very cool. Thanks.
On 01/05/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> FYI I independently built the C++ broker from M2 on a similar 64-bit
> computer (Fedora Core 6 x86-64) last night. I got it running, and
> connected using the java client and managed a fair degree of
> interaction.
>
> Eventually the broker seemed to hang, but it was too late at night to
> start trying to diagnose. Hopefully I'll get another chance to look
> at it this evening (the computer is at home).
>
> I downloaded and built all the known AMQ brokers (qpid, RabbitMQ and
> OpenAMQ) last night and will have a play at getting some interop and
> performance stats out of them as I get a chance...
>
> Cheers,
> Rob
>
> On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> > On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > > I've been working on the M2 branch also and haven't seen the
> problem.
> > > > Soon as I finish my current commit I'll make an RPM for you to try.
> > >
> > > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> > >
> > > Cheers,
> > > Alan.
> > >
> >
> > Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> > is the same. I must have some incompatible item installed. Do you have
> > 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
> >
> > Cheers
> > --
> > Martin Ritchie
> >
>
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2007-05-01 at 08:23 +0100, Robert Godfrey wrote:
> FYI I independently built the C++ broker from M2 on a similar 64-bit
> computer (Fedora Core 6 x86-64) last night. I got it running, and
> connected using the java client and managed a fair degree of
> interaction.
>
> Eventually the broker seemed to hang, but it was too late at night to
> start trying to diagnose. Hopefully I'll get another chance to look
> at it this evening (the computer is at home).
>
Keep me informed. This plus Martin's problems may point to a race
condition somewhere in qpidd. I'll set up some stress tests and see if I
can reproduce it locally.
Cheers,
Alan.
Re: [C++] Build
Posted by Robert Godfrey <ro...@gmail.com>.
FYI I independently built the C++ broker from M2 on a similar 64-bit
computer (Fedora Core 6 x86-64) last night. I got it running, and
connected using the java client and managed a fair degree of
interaction.
Eventually the broker seemed to hang, but it was too late at night to
start trying to diagnose. Hopefully I'll get another chance to look
at it this evening (the computer is at home).
I downloaded and built all the known AMQ brokers (qpid, RabbitMQ and
OpenAMQ) last night and will have a play at getting some interop and
performance stats out of them as I get a chance...
Cheers,
Rob
On 01/05/07, Martin Ritchie <ri...@apache.org> wrote:
> On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> > On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > > I've been working on the M2 branch also and haven't seen the problem.
> > > Soon as I finish my current commit I'll make an RPM for you to try.
> >
> > Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> > http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> > http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
> >
> > Cheers,
> > Alan.
> >
>
> Thanks for the RPMs Alan. I wish I had better news, but the behaviour
> is the same. I must have some incompatible item installed. Do you have
> 32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
>
> Cheers
> --
> Martin Ritchie
>
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> > I've been working on the M2 branch also and haven't seen the problem.
> > Soon as I finish my current commit I'll make an RPM for you to try.
>
> Martin, if you're still looking for an M2 x86_64 build try these RPMs:
> http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
> http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
>
> Cheers,
> Alan.
>
Thanks for the RPMs Alan. I wish I had better news, but the behaviour
is the same. I must have some incompatible item installed. Do you have
32Bit rpm's to hand. Perhaps I can try and narrow down the problem.
Cheers
--
Martin Ritchie
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2007-04-30 at 13:02 -0400, Alan Conway wrote:
> I've been working on the M2 branch also and haven't seen the problem.
> Soon as I finish my current commit I'll make an RPM for you to try.
Martin, if you're still looking for an M2 x86_64 build try these RPMs:
http://rhm.et.redhat.com/download/qpidd-0.1-5.M2.x86_64.rpm
http://rhm.et.redhat.com/download/qpidc-0.1-5.M2.x86_64.rpm
Cheers,
Alan.
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2007-04-30 at 17:49 +0100, Martin Ritchie wrote:
> You are totally right Alan,
>
> I'm new to 64bit chips and didn't realise the libs were in lib64
> (Doh!) I think the newest chip in a linux box I have is a celeron.
>
> So setting PKG_CONFIG to /usr/lib64/pkg_config and all is good... well
> until you come to run it :)
>
> It all seems to start fine netstat shows it is listening but I can't
> connect, telnet nor python tests. -t doesn't increase the verbosity at
> startup so I'm a little stuck, if I've got time I'll try a 32bit build
> (though I've just removed all the 32bit libs :))
>
> ptrace looks ok.(See end of email)
>
> I forgot to say this is a build from M2.
>
> If you have a working 64bit qpidd I could try that out and see if it
> is something to do with my linking rather than my codebase. Which it
> probably is.. all my libs are the versions specfied in the README or
> newer. Will investigate further tomorrow.
>
> Thanks for the help,
I've been working on the M2 branch also and haven't seen the problem.
Soon as I finish my current commit I'll make an RPM for you to try.
Cheers,
Alan.
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
You are totally right Alan,
I'm new to 64bit chips and didn't realise the libs were in lib64
(Doh!) I think the newest chip in a linux box I have is a celeron.
So setting PKG_CONFIG to /usr/lib64/pkg_config and all is good... well
until you come to run it :)
It all seems to start fine netstat shows it is listening but I can't
connect, telnet nor python tests. -t doesn't increase the verbosity at
startup so I'm a little stuck, if I've got time I'll try a 32bit build
(though I've just removed all the 32bit libs :))
ptrace looks ok.(See end of email)
I forgot to say this is a build from M2.
If you have a working 64bit qpidd I could try that out and see if it
is something to do with my linking rather than my codebase. Which it
probably is.. all my libs are the versions specfied in the README or
newer. Will investigate further tomorrow.
Thanks for the help,
On 30/04/07, Alan Conway <ac...@redhat.com> wrote:
> On Mon, 2007-04-30 at 15:10 +0100, Martin Ritchie wrote:
> > On 30/04/07, Gordon Sim <gs...@redhat.com> wrote:
> > > Martin Ritchie wrote:
> > > > Hey C++ fokes,
> > > >
> > > > I've been following the README but I've hit a sumbling block in
> > > > building the C++ broker
> > > >
> > > > to summerize steps to this points
> > > >
> > > > Building on Dual Core Xeon under Fedora 6.
> > > >
> > > > Installed updates apr etc via yum.
> > > >
> > > > and used the autotools install script to download tools to ~/qpid-tools.
> > > >
> > > > then
> > > > [qpid@wglaibb3pjr2j cpp]$ ./bootstrap
> > > > docs/api/Makefile.am:9: wildcard $(top_srcdir: non-POSIX variable name
> > > > docs/api/Makefile.am:9: (probably a GNU make extension)
> > > >
> > > > Is this ok?
> > >
> > > Yes, that is ok.
> > >
> > > > and ./configure was quite happy
> > > >
> > > > but make gets upset about the file format of /usr/lib/libapr-1.so ..
> > > > this is a sym-link to libapr-1.so.0.2.7
> > > >
> > > > I'm a bit rusty on the building of C++, Linux apps.
> > > >
> > > > Any thoughts? Do you need more info?
> > >
> > > Could the wrong build of apr perhaps have been installed? Sounds
> > > unlikely if you used yum... Does 'apr-1-config --version' work? or
> > > running ldd against /usr/lib/libapr-1.so?
> >
> > Everything seems to be in place? Could it be a 64bit issue? I can't
> > think why the binary file might be the "wrong format".
> >
> > [qpid@wglaibb3pjr2j java]$ apr-1-config --version
> > 1.2.7
> > [qpid@wglaibb3pjr2j java]$ ldd /usr/lib/libapr-1.so
> > linux-gate.so.1 => (0xffffe000)
> > libuuid.so.1 => /lib/libuuid.so.1 (0xf7fb7000)
> > libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f89000)
> > libpthread.so.0 => /lib/libpthread.so.0 (0xf7f72000)
> > libdl.so.2 => /lib/libdl.so.2 (0xf7f6e000)
> > libc.so.6 => /lib/libc.so.6 (0xf7e30000)
> > /lib/ld-linux.so.2 (0x56555000)
> > [qpid@wglaibb3pjr2j java]$
> >
>
> I think this is a 64bit problem, I've just started building on a 64bit
> box and the "invalid format" for libraries is very familiar to me!
>
> Is /usr/lib64/apr installed on your box? I don't really understand how
> RPM manages 64 bit libs yet, you should have what looks like two copies
> of the RPM installed, one of which has the 64bit libs.
>
> Here's what I get on the 64bit box I build on:
>
> [aconway@qpid ~]$ rpm -q apr
> apr-1.2.7-11
> apr-1.2.7-11
> [aconway@qpid ~]$ rpm -ql apr
> /usr/lib/libapr-1.so.0
> /usr/lib/libapr-1.so.0.2.7
> /usr/share/doc/apr-1.2.7
> /usr/share/doc/apr-1.2.7/CHANGES
> /usr/share/doc/apr-1.2.7/LICENSE
> /usr/share/doc/apr-1.2.7/NOTICE
> /usr/lib64/libapr-1.so.0
> /usr/lib64/libapr-1.so.0.2.7
> /usr/share/doc/apr-1.2.7
> /usr/share/doc/apr-1.2.7/CHANGES
> /usr/share/doc/apr-1.2.7/LICENSE
> /usr/share/doc/apr-1.2.7/NOTICE
>
>
>
>
--
Martin Ritchie
Thread 7 (Thread 1084229952 (LWP 11153)):
#0 0x00002aaaab259607 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
#1 0x00002aaaab023293 in apr_thread_cond_timedwait ()
#2 0x00002aaaaaada7b1 in qpid::broker::AutoDelete::run ()
#3 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#4 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#5 0x00000037426cd62d in clone () from /lib64/libc.so.6
#6 0x0000000000000000 in ?? ()
Thread 6 (Thread 1094719808 (LWP 11154)):
#0 0x00000037426cda18 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x00002aaaab029708 in apr_pollset_poll () from /usr/lib64/libapr-1.so.0
#2 0x00002aaaaad98ed4 in qpid::sys::LFProcessor::poll ()
#3 0x00002aaaaad98ef8 in qpid::sys::LFProcessor::getNextEvent ()
#4 0x00002aaaaad9b847 in qpid::sys::LFProcessor::run ()
#5 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#6 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#7 0x00000037426cd62d in clone () from /lib64/libc.so.6
#8 0x0000000000000000 in ?? ()
Thread 5 (Thread 1105209664 (LWP 11155)):
#0 0x00002aaaab25b7f8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1 0x00002aaaab25789a in _L_mutex_lock_908 () from /lib64/libpthread.so.0
#2 0x00002aaaab257722 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002aaaaad9b824 in qpid::sys::LFProcessor::run ()
#4 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#5 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#6 0x00000037426cd62d in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 4 (Thread 1115699520 (LWP 11156)):
#0 0x00002aaaab25b7f8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1 0x00002aaaab25789a in _L_mutex_lock_908 () from /lib64/libpthread.so.0
#2 0x00002aaaab257722 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002aaaaad9b824 in qpid::sys::LFProcessor::run ()
#4 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#5 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#6 0x00000037426cd62d in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 3 (Thread 1126189376 (LWP 11157)):
#0 0x00002aaaab25b7f8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1 0x00002aaaab25789a in _L_mutex_lock_908 () from /lib64/libpthread.so.0
#2 0x00002aaaab257722 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002aaaaad9b824 in qpid::sys::LFProcessor::run ()
#4 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#5 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#6 0x00000037426cd62d in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 1136679232 (LWP 11158)):
#0 0x00002aaaab25b7f8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1 0x00002aaaab25789a in _L_mutex_lock_908 () from /lib64/libpthread.so.0
#2 0x00002aaaab257722 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00002aaaaad9b824 in qpid::sys::LFProcessor::run ()
#4 0x00002aaaaada1477 in qpid::sys::Thread::runRunnable ()
#5 0x00002aaaab255305 in start_thread () from /lib64/libpthread.so.0
#6 0x00000037426cd62d in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 1 (Thread 46912508673984 (LWP 11139)):
#0 0x00002aaaab25be1b in __accept_nocancel () from /lib64/libpthread.so.0
#1 0x00002aaaab026e94 in apr_socket_accept () from /usr/lib64/libapr-1.so.0
#2 0x00002aaaaad954a3 in qpid::sys::APRAcceptor::run ()
#3 0x0000000000407fc5 in main ()
#0 0x00002aaaab25be1b in __accept_nocancel () from /lib64/libpthread.so.0
Re: [C++] Build
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2007-04-30 at 15:10 +0100, Martin Ritchie wrote:
> On 30/04/07, Gordon Sim <gs...@redhat.com> wrote:
> > Martin Ritchie wrote:
> > > Hey C++ fokes,
> > >
> > > I've been following the README but I've hit a sumbling block in
> > > building the C++ broker
> > >
> > > to summerize steps to this points
> > >
> > > Building on Dual Core Xeon under Fedora 6.
> > >
> > > Installed updates apr etc via yum.
> > >
> > > and used the autotools install script to download tools to ~/qpid-tools.
> > >
> > > then
> > > [qpid@wglaibb3pjr2j cpp]$ ./bootstrap
> > > docs/api/Makefile.am:9: wildcard $(top_srcdir: non-POSIX variable name
> > > docs/api/Makefile.am:9: (probably a GNU make extension)
> > >
> > > Is this ok?
> >
> > Yes, that is ok.
> >
> > > and ./configure was quite happy
> > >
> > > but make gets upset about the file format of /usr/lib/libapr-1.so ..
> > > this is a sym-link to libapr-1.so.0.2.7
> > >
> > > I'm a bit rusty on the building of C++, Linux apps.
> > >
> > > Any thoughts? Do you need more info?
> >
> > Could the wrong build of apr perhaps have been installed? Sounds
> > unlikely if you used yum... Does 'apr-1-config --version' work? or
> > running ldd against /usr/lib/libapr-1.so?
>
> Everything seems to be in place? Could it be a 64bit issue? I can't
> think why the binary file might be the "wrong format".
>
> [qpid@wglaibb3pjr2j java]$ apr-1-config --version
> 1.2.7
> [qpid@wglaibb3pjr2j java]$ ldd /usr/lib/libapr-1.so
> linux-gate.so.1 => (0xffffe000)
> libuuid.so.1 => /lib/libuuid.so.1 (0xf7fb7000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f89000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xf7f72000)
> libdl.so.2 => /lib/libdl.so.2 (0xf7f6e000)
> libc.so.6 => /lib/libc.so.6 (0xf7e30000)
> /lib/ld-linux.so.2 (0x56555000)
> [qpid@wglaibb3pjr2j java]$
>
I think this is a 64bit problem, I've just started building on a 64bit
box and the "invalid format" for libraries is very familiar to me!
Is /usr/lib64/apr installed on your box? I don't really understand how
RPM manages 64 bit libs yet, you should have what looks like two copies
of the RPM installed, one of which has the 64bit libs.
Here's what I get on the 64bit box I build on:
[aconway@qpid ~]$ rpm -q apr
apr-1.2.7-11
apr-1.2.7-11
[aconway@qpid ~]$ rpm -ql apr
/usr/lib/libapr-1.so.0
/usr/lib/libapr-1.so.0.2.7
/usr/share/doc/apr-1.2.7
/usr/share/doc/apr-1.2.7/CHANGES
/usr/share/doc/apr-1.2.7/LICENSE
/usr/share/doc/apr-1.2.7/NOTICE
/usr/lib64/libapr-1.so.0
/usr/lib64/libapr-1.so.0.2.7
/usr/share/doc/apr-1.2.7
/usr/share/doc/apr-1.2.7/CHANGES
/usr/share/doc/apr-1.2.7/LICENSE
/usr/share/doc/apr-1.2.7/NOTICE
Re: [C++] Build
Posted by Martin Ritchie <ri...@apache.org>.
On 30/04/07, Gordon Sim <gs...@redhat.com> wrote:
> Martin Ritchie wrote:
> > Hey C++ fokes,
> >
> > I've been following the README but I've hit a sumbling block in
> > building the C++ broker
> >
> > to summerize steps to this points
> >
> > Building on Dual Core Xeon under Fedora 6.
> >
> > Installed updates apr etc via yum.
> >
> > and used the autotools install script to download tools to ~/qpid-tools.
> >
> > then
> > [qpid@wglaibb3pjr2j cpp]$ ./bootstrap
> > docs/api/Makefile.am:9: wildcard $(top_srcdir: non-POSIX variable name
> > docs/api/Makefile.am:9: (probably a GNU make extension)
> >
> > Is this ok?
>
> Yes, that is ok.
>
> > and ./configure was quite happy
> >
> > but make gets upset about the file format of /usr/lib/libapr-1.so ..
> > this is a sym-link to libapr-1.so.0.2.7
> >
> > I'm a bit rusty on the building of C++, Linux apps.
> >
> > Any thoughts? Do you need more info?
>
> Could the wrong build of apr perhaps have been installed? Sounds
> unlikely if you used yum... Does 'apr-1-config --version' work? or
> running ldd against /usr/lib/libapr-1.so?
Everything seems to be in place? Could it be a 64bit issue? I can't
think why the binary file might be the "wrong format".
[qpid@wglaibb3pjr2j java]$ apr-1-config --version
1.2.7
[qpid@wglaibb3pjr2j java]$ ldd /usr/lib/libapr-1.so
linux-gate.so.1 => (0xffffe000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf7fb7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7f89000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7f72000)
libdl.so.2 => /lib/libdl.so.2 (0xf7f6e000)
libc.so.6 => /lib/libc.so.6 (0xf7e30000)
/lib/ld-linux.so.2 (0x56555000)
[qpid@wglaibb3pjr2j java]$
--
Martin Ritchie
Re: [C++] Build
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> Hey C++ fokes,
>
> I've been following the README but I've hit a sumbling block in
> building the C++ broker
>
> to summerize steps to this points
>
> Building on Dual Core Xeon under Fedora 6.
>
> Installed updates apr etc via yum.
>
> and used the autotools install script to download tools to ~/qpid-tools.
>
> then
> [qpid@wglaibb3pjr2j cpp]$ ./bootstrap
> docs/api/Makefile.am:9: wildcard $(top_srcdir: non-POSIX variable name
> docs/api/Makefile.am:9: (probably a GNU make extension)
>
> Is this ok?
Yes, that is ok.
> and ./configure was quite happy
>
> but make gets upset about the file format of /usr/lib/libapr-1.so ..
> this is a sym-link to libapr-1.so.0.2.7
>
> I'm a bit rusty on the building of C++, Linux apps.
>
> Any thoughts? Do you need more info?
Could the wrong build of apr perhaps have been installed? Sounds
unlikely if you used yum... Does 'apr-1-config --version' work? or
running ldd against /usr/lib/libapr-1.so?