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 <[email protected]>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 > [email protected] > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
