[openamq-dev] porting to Ubuntu

Martin Lucina mato at imatix.com
Wed Aug 22 12:34:29 CEST 2007


Nick,

ndl at ravenbrook.com said:
> I don't know whether the following is relevant. The system I'm working
> with can only link with shared libraries. After building OpenAMQ, I
> went on to link the archives in ibase/lib thus:
> 
>   ld -shared -o libamq.so -luuid -lm -whole-archive libamq_common.a  \
>     libamq_operate.a libamq_server.a libamq_wireapi.a libapr.a \
>     libaprutil.a libasl.a libicl.a libipr.a libpcre.a libsfl.a libsmt3.a \
>     libsmt.a libzip.a /usr/lib/libexpat.so.1 /usr/lib/libcrypt.a

That explains it ...

All code going into a shared library has to be compiled with -fPIC,
otherwise bad things happen, especially if the library uses static
variables which is the case here (s_os_active_thread_count).

> I don't know. Machine isn't mine, it's remote to me (I access it via
> ssh). What's the incantation for finding out?

cat /proc/cpuinfo, but it's not relevant since I can see that it's the
.so that's causing the problem.

>    4) Does our standard client code work correctly? e.g. Can you run
>    "amq_server" and "amq_client" with no parameters against it?
> 
> Yes, and amq_shell

Just to confirm 100% that it *is* the .so, can you try manually linking
amq_client against the .so rather than the static libraries? You can get
the link command by doing "c -v -L amq_client" in the
OpenAMQ-XXX/clients directory. Take out the .a files and specify the
full path to your shared library.

I'd expect it to not work ...

Once we confirm that this is the case, we can look at a temporary
solution to make the shared library work for you.

-mato


More information about the openamq-dev mailing list