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

[Mark Marsella]

What's more likely that the whole "unix way" is broken or you and the op
don't really understand their environment and how it is setup re building.

I have built whole Linux distributions, desktop environments, browsers,
libraries (including zmq) without an issue as have many others.

Also many of the world's important software is written in C
and continues to be, in my opinion C++ is a badly designed language and
would advise people who need their hand held by the compiler use Java.

On 22 February 2012 03:46, john skaller <skaller at users.sourceforge.net>wrote:

>
> 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
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120222/154afea0/attachment.htm>