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

[john skaller]

On 22/02/2012, at 1:54 PM, Kushal Dalmia wrote:

> Hi,
> 
> I finally got it to work. The problem was the location where RHEL
> creates the libstdc++.so. It was in /usr/lib (and /usr/lib64). On
> adding these to the LD_LIBRARY_PATH, the issue got resolved.
> 
> Thanks a lot to everybody for their support.


I'm confused. You shouldn't need to do this. /usr/lib is a *builtin*
resolution path, you do not need to add it to LD_LIBRARY_PATH,
that path is only for *extra* libraries not installed in a standard 
place.

For example on my Mac:

>echo $DYLD_LIBRARY_PATH
/opt/local/lib:

As to /usr/lib64

you *should not* add that to your LD_LIBRARY_PATH.
This will only confuse the linker. The linker can choose 
between 32 and 64 bit libraries automatically.

If you set a 64 bit only directory in the path you're
interfering with the linkers resolution algorithm.

IMHO: you have not resolved your issue just because it now works.
You have only resolved the issue when you fully understand why
it did not work before. 

It *should* have worked. Linking C code to C++ is problematic:
you're running gcc not g++. You should always write C++ programs
and use g++ anyhow, even if your code is meant to be C, since
C++ provides much better type safety, even for C programs.

You might try compiling your example with g++ explicitly, and then
also try renaming it to hello.cpp and compiling and linking with that,
to see if the problem is in the way gcc/g++ is calling the linker.

I'd also try forcing both dynamic and static linkage.
You may need -fPIC to make dynamic work; it is required
on an x86_64 machine for library code. 
Standard *.o files cannot be linked into shared dynamic libraries: 
the actual machine instructions required to call out are different.

BTW: it took me a year to figure out a half decent linkage model.
People need to understand that the old school unix way is finished.
It doesn't work on modern systems. Pretty much all libraries
(including 0MQ) are installed incorrectly, and most package managers
(especially Debian) are also using the wrong model.
For example Python is installed properly on OSX, but incorrectly
on all Debian based Linux boxes. The model chosen there is suitable
for basic usage but doesn't work properly with embedding.

It's pretty serious really. I have applications which work on OSX and
fail on Linux, because the Linux is so confused it messes up 
standard I/O. Standard I/O is very hard to do right unless you use 
a workable linkage model (global variables trash linkage
on Unix unless you take special care).

--
john skaller
skaller at users.sourceforge.net