Just to jump in here. On OS X I also noticed that X11 libs are linked into VTK 502 even though I am compiling with Carbon.. Is that correct? Doesn't seem so.
Mike Jackson On 10/20/06 3:20 PM, "Patrick D. Emond" <[EMAIL PROTECTED]> wrote: > For those people who, like me, are primarily interested in getting VTK5 > built under cygwin the simplest solution seems to be to make sure that > your cygwin install has no X11 libraries installed. I completely > reinstalled cygwin making sure to not include any X11 packages and the > VTK install went off without a hitch (no need to change the > CMakeCache.txt file after running CMake). > > Hope that helps someone. > > - Patrick > > > Steve Robbins wrote: >> Hello all, >> >> This thread begins at >> http://public.kitware.com/pipermail/vtkusers/2006-September/087106.html >> >> >> Quoting Steve Robbins <[EMAIL PROTECTED]>: >> >>> I'm having the same problem as Patrick D. Emond >>> [http://public.kitware.com/pipermail/vtkusers/2006-September/086953.html] >>> in >>> building VTK under cygwin. >> >> To recap: I am building VTK 5 sources on cygwin under windows XP. The >> initial >> build failed with link errors. Cygwin provides two different OpenGL >> implementations: one that runs on top of X11 and one that doesn't. The >> cause of >> the link errors is that the compilation used gl.h from X11 but linked >> against >> the non-X11 GL library. >> >> I configured with VTK_USE_X set to OFF. However, CMake saw fit to add >> -I/usr/X11R6/include to the compile command line and therefore brought >> in the >> wrong gl.h. >> >> In a series of emails with helpful folks like David Cole and Brad King I >> learned the following: >> >> 0. A workaround exists: after configuring, edit CMakeCache.txt to set >> the OPENGL_* variables correctly, reconfigure, and build. >> >> 1. The only way to debug CMake's actions is to sprinkle MESSAGE() >> throughout >> its input files, including those in /usr/share/cmake-2.4.3. >> >> 2. The symbol WIN32 *is* defined on cygwin, contrary to my initial >> speculation. >> >> 3. The file /usr/share/cmake-2.4.3/Modules/FindOpenGL.cmake has the >> following >> code: >> >> IF (WIN32) >> IF (CYGWIN) >> >> FIND_PATH(OPENGL_INCLUDE_DIR GL/gl.h >> /usr/include >> /usr/include/w32api >> /usr/X11R6/include >> ) >> >> Despite the existence of /usr/include/w32api/GL/gl.h, the variable >> OPENGL_INCLUDE_DIR is set to /usr/X11R6/include by this code. This is >> *not* an effect of CMake caching, nor have I defined the environment >> variable INCLUDE. >> >> What is happening is that FIND_PATH() searches an internal, hard-coded set >> of paths *before* the paths specified in the arguments. This set of >> paths happens to include /usr/X11R6/include, so if that directory contains >> GL/gl.h, there's no way /usr/include/w32api/GL/gl.h (the correct, non-X11 >> header) will be found. >> >> At this point, deep in a private email thread, the speculation became >> that the internal set of include paths was in the wrong order. In fact, >> however, there is no possible correct ordering if one wants to support >> building with both versions of OpenGL, based on a build-time configuration >> variable (VTK_USE_X). Rather, I think, the code in FindOpenGL.cmake should >> resemble the following: >> >> IF(VTK_USE_X) >> FIND_PATH( OPENGL_INCLUDE_DIR GL/gl.h /usr/X11R6/include >> NO_DEFAULT_PATH ) >> ELSE >> FIND_PATH( OPENGL_INCLUDE_DIR GL/gl.h /usr/include/w32api >> NO_DEFAULT_PATH ) >> ENDIF >> >> The trouble is, of course, that FindOpenGL.cmake has no knowledge of >> "VTK_USE_X". >> >> It's clear that there's a bug: building on cygwin should work >> out-of-the-box >> for both settings of VTK_USE_X. It's less clear (to me) whether the bug >> should >> be fixed in VTK or in CMake. >> >> -Steve >> _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
