Description of Problem: Shared library libGLU.so from XFree86-devel-4.2.0-8 seems to be improperly formed. When building another application's shared library (OpenInventor) that uses libGLU, I get strange errors that vary with compiler used. In my application the KCC-compiled versions of OpenInventor linked with libGLU will fail in __dynamic_cast (in fact the assembler version of that routine revealed by the debugger doesn't seem to be the correct version). When everything is compiled with Portland's pgCC compiler, (as well as the OpenInventor stuff that depends on libGLU), I get a run-time link error that "stat" is missing. Intel's icc compiler seems to produce working code. This seems to be a new feature with RedHat 7.3, the same set of applications worked fine with RedHat 7.1. If I merely rebuild libGLU.so with "gcc -shared -Wl,--whole-archive libGLU.a --no-whole-archive -o libGLU.so.new" and use that version to link against when building the Inventor libraries and my own application, then all seems to work fine. Version-Release number of selected component (if applicable):libGLU.1.3 How Reproducible: (See description above) Steps to Reproduce: 1. Build the shared libraries for OpenInventor (which depend on libGLU) 2. 3. Actual Results: Expected Results: Additional Information:
libGLU is written in C++. You can't compile C++ code with an arbitary compiler, and link it to C++ libraries compiled with another compiler such as gcc. You must compile the code using gcc, or you must recompile the libraries you're using (libGLU) with the compiler you're using. Even then there are no guarantees of this working, and Red Hat does not support it. If it is found that libGLU does not work, or has these problems when compiled with an alternative compiler, please report any such problems to XFree86.org.
Actually libGLU contains both C and C++ modules. The interface exposed by /usr/include/glu.h seems to only contain the C modules for general use, and those are just the routines needed by OpenInventor. I agree that the C++ modules, if refrenced externally to the library in code compiled by other than g++, would not properly link, due to differences in name mangling. However, the modules sought are the C modules, and they can always be found. My application using OpenInventor actually does link, so no references are being made to the C++ modules in libGLU. However at run time, there is strange behavior. I stand by my claim that the shared library libGLU.so has been improperly formed from the libGLU.a archive. If I rebuild the shared library in the manner described, my code (and the openinventor stuff) once again works as it did under RedHat7.1 Of all the graphics libraries I use in this project (libGL, libX11, libXt, libXm, libXmu, libXt, libXi, libXp, libSM, libICE) only libGLU is causing problems now under RedHat7.3. Though I don't think it is a compilation/name-mangling issue, I would gladly recompile libGLU with my local compiler, but I can't find the source from RedHat, XFree86, or SGI. Perhaps I just haven't looked hard enough.
Red Hat does not support using externally supplied compilers. If you are having a problem with a non Red Hat supplied compiler, and a library shipped with Red Hat Linux, it is recommended that you contact the upstream maintainers of the given library for support. We only support gcc 2.96 as shipped with Red Hat Linux 7.3.
I see you are convinced it is compiler bug. It isn't. It's a library build bug.
I did not say it was a compiler bug. I said your compiler is not supported by Red Hat for usage in development. Red Hat supports the gcc compiler shipped in the distribution only. Such a bug, may indeed be a bug in the software, but it is not a bug which Red Hat supports debugging/troubleshooting or fixing. Any software bugs that are triggered by other compilers/etc. are problems that upstream developers of the given software need to fix/resolve. As such, and assuming the problem is in fact a real bug/problem, it is something that needs to be addressed by XFree86.org upstream and/or whomever maintains libGLU. You can report this problem to xfree86 in order to have the XFree86 core development team look into this issue for you. I'm once again closing this bug as WONTFIX. Again, it is officially not supported, and I'm not sure how I can make that much clearer than I've already stated above. There is no need to reopen it again, as that isn't going to change the fact that the problem falls in the unsupported domain.