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

Robin Cornelius robin.cornelius at gmail.com
Tue Aug 5 01:02:34 PDT 2008


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.


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.

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.

Regards

Robin


More information about the SLDev mailing list