Compilation problem on Red-Hat RHEL6

I have a very simple compilation problem on RHEL6, and I would like the best recommendation to overcome it. On Red-Hat, most 64-bit shared libraries are located on directory /usr/lib64/ but old 32-bit libraries are often left at their original location. During the compilation of Salome using "python runInstall", I click "Install sources and make a compilation". During the installation of gl2ps, I got the following message:
/usr/local/lib/libGLU.so : could not read symbols : File in wrong format
The problem is caused by the search path of LD_LIBRARY_PATH. The libGLU.so library found is an old 32-bit library. The correct library is located in /usr/lib64/libGLU.so.
To correct the situation, I tried to add "/usr/lib64:" at start of LD_LIBRARY_PATH in line 1169 of runInstall script. Without success. Of course, my system administrator refuse to modify /usr/local/lib/.
Any suggestion?
No reply after 5 days, so I decided to solve the problem by myself. The problem is caused by two makefiles files making references to old 32-bit libraries in building gl2ps. This is apparently not a problem on Debian/Calibre systems over which SALOME is developed, but is harmful on RHEL6. By the fact, RHEL6 is frequently used in industry and academia in North-America. It would be nice to investigate if this is a bug or a feature. The faulty files are:
salome_6.6.0/gl2ps-1.3.5_SRC/CMakeCache.txt
salome_6.6.0/gl2ps-1.3.5_SRC/CMakeFiles/shared.dir/build.make
The corrected files are attached.
Hello Alain,
I dont quite understand where the problem comes from.
Is it from the Salome build procedure or from gl2ps itself ?
The OpenGL libraries are detected using a CMake macro: find_package(OpenGL). If the libraries are badly detected then it comes from this macro.
Did you fix the CMakeLists.txt in the gl2ps source directory and then generated the files, or did you change the CMakeCache.txt manually ?
Regards,
Gilles
What I did was to fix directly the two files mentioned in my post and to relaunch "python runInstall". It works. However, I did not check if these two files were generated previously by a CMake macro. Sorry.
The mentioned files are generated by the detection process of CMake. You can help it by setting proper values for some variables. This is what you did by manually chaging CMakeCache.txt.
Anyway, this problem seems not specific to Salome but related to gl2ps.
To be sure, one should compile gl2ps independently of Salome to check where the OpenGl libraries are detected.
My conclusions at this point:
To compile SALOME on RHEL6, I patched the following CMake generated files:
salome_6.6.0/gl2ps-1.3.5_SRC/CMakeCache.txt
salome_6.6.0/gl2ps-1.3.5_SRC/CMakeFiles/shared.dir/build.make
Someone reported a similar problem here: http://www.opengl.org/discussion_boards/showthread.php/171607-glXChooseVisual-is-failing
Don't you have a 32bit and a 64bit version of the GL driver on your system ?
Previously DAVID Gilles wrote:
Someone reported a similar problem here: http://www.opengl.org/discussion_boards/showthread.php/171607-glXChooseVisual-is-failing
Don't you have a 32bit and a 64bit version of the GL driver on your system ?
Right. This is a problem with my X11 emulator. I am using two. The first is XQuartz 2.7.4 on MacOSX. It is giving problems with Geometry. The second is Xming on Windows7. It is working correctly with the precompiled version of Salome. I will continue my work with this one. Thanks!