[zeromq-dev] Issues installing ZeroMQ and PyZMQ on RHEL 6

[john skaller]

On 22/02/2012, at 7:07 AM, Kushal Dalmia wrote:

> Hi,
> 
> I did write a short program and linked it with ZMQ. This is the
> behaviour I found:
> $ gcc -lzmq -o testzmq testzmq.c => Fails with the same errors (as in
> attached file)

How do you know you're dynamic linking?

> 
> However,
> $ gcc -L/usr/local/lib -lzmq -o testzmq testzmq.c ==> Successfully
> Compiles and links!

Is is statically or dynamically linked to libzmq and libstdc++?

> 
> Here are the required outputs:


> 15:04:48 # ldd libzmq.so
> 	linux-vdso.so.1 =>  (0x00007fff695a8000)
> 	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4a3f8d5000)
> 	librt.so.1 => /lib64/librt.so.1 (0x00007f4a3f6cc000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4a3f4af000)
> 	libstdc++.so.6 => /usr/local/lib/../lib64/libstdc++.so.6 (0x00007f4a3f39f000)


I you linked libzmq.so with the same paths, this cannot fail,
assuming the targeted libs are actually there.

The fact it's failing suggests the evil ld program is silently switching
to static linkage .. and its the static link that's failing and needs
the -L switch.

The dynamic link doesn't need a -L switch to find secondary libraries.

<flame>
All library vendors have it wrong, providing libxxx.so and libxxx.a,
this is a really bad idea, the names should always be distinct
because the linkage command line scripts must be as well.

I guess libtool tries to fix that, not sure because I use a different toolset.

Underneath it's ld that's evil, trying to make something transparent
that isn't. Of course it USED to be in the old days. But not on x86_64
with shared libraries.
</flame>

--
john skaller
skaller at users.sourceforge.net