[sldev] [VWR] cmake issues with libGL and friends

Bill Hoffman bill.hoffman at kitware.com
Tue Aug 5 07:03:23 PDT 2008


Robin Cornelius wrote:
> On Thu, Jul 31, 2008 at 3:44 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
>> Robin Cornelius wrote:
> 
>>> Been testing with cmake-2.6.1-RC15 but i still get a link error
>>> related to libGL and libGLU, the error is coming from the fact that
>>> ${OPENGL_LIBRARIES} is providing the linker lines -lGL and -lGLU which
>>> is of cause picking up my system installed libraries in /usr/lib in
>>> preference to any others. In fact cmake gave a warning to that effect
>>> that the libraries in ../i686-linux/lib-release and lib_release_client
>>> may not be found as default system search paths will override.
>> If you give CMake a full path to the GL and GLU libraries that are not the
>> system libraries, then it will use those.  Looks like the STANDALONE logic
>> is not quite right for GL.   However, if you edit the CMakeCache.txt or give
>> a -D option and set the following cache variables to the full path to the
>> libraries in ../i686-linux/lib-release (with extension):
>>
>> OPENGL_gl_LIBRARY
>> OPENGL_glu_LIBRARY
>>
>> Then it should work.
>>
> 
> Hi Bill sorry for the late reply but i've been fiddling with this since.
> 
> It seems that the issue i am seeing is related to if the linden
> supplied libGL.a is present in the linden library dirs. My testing
> indicated that in a clean chroot with no mesa libs etc i could not
> link with out errors relating to gl functions being already defined.
> Having the mesa libs present is /usr/lib/ did not solve the issue
> until i also deleted the libGL.a from the linden library dirs.
> 
> In fairness cmake warned me that there was a library name conflict and
> that two conflicting libraries existed in two search locations but it
> then looks like ld chokes on the results and i can't see why this bit
> is cmakes fault in anyway.
> 
If you put the mesa libs in any directory other than /usr/lib, it would 
work.   With /usr/lib CMake does not use full path libraries.  This is 
because some linkers play tricks with this directory.   So, it should 
work if you put mesa in some other directory.
> 
> I have hit an additional 2.6.1 issue post linking (now i can get that
> far). The package commands for linux are not running on 2.6.1, things
> package up correctly on cmake 2.4. It seems that the targets that are
> set as custom commands in newview/CMakeList.txt ar not making it to
> the actual makefile so there is no secondlife-stripped rule no
> secondlife-bin-globalsym rule and no SecondLife-1.20.15.tar.bz rule :-
> 
> make[2]: *** No rule to make target
> `../newview/SecondLife-x86_64-1.20.15.0.tar.bz2', needed by
> `newview/CMakeFiles/package.
> 
> The same issue hits me on i386 or amd64 and it does not matter if i
> use standalone or normal build. So its something to do with the way
> the custom commands are added to produce make targets.
> 
Bummer on this one....  Looks like a cmake 2.6.1 bug...

If you change the code to this:
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2
...
add_custom_target(package ALL DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2)

It will work.  However, cmake should have done the right thing.  I will 
work on a  fix.

> The unix install targets do seem to be working, although there may be
> some small issues, i need to do further testing on this bit.


-Bill


More information about the SLDev mailing list