The cmake bug report is now marked resolved and it appears it will be included in the cmake 2.8.5 release.  I haven't had a chance to try it out yet, but if you pull cmake master you should have the fix.<br><br>Pat<br>
<br><div class="gmail_quote">On Tue, Jun 28, 2011 at 9:10 AM, Dominik Szczerba <span dir="ltr"><<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear Andrew,<br>
<br>
Many thanks for the invaluable hint! I knew about the Ubuntu multiarch<br>
issue, but did not immediately identify its incarnation here.<br>
<br>
I actually did not yet try patching any cmake files as advised in the<br>
bug report, I just installed Ubuntu-bundled cmake 2.8.3 and removed my<br>
own compiled 2.8.4. This was also the critical difference between the<br>
two of my systems...<br>
<br>
Thanks again,<br>
Dominik<br>
<br>
On Tue, Jun 28, 2011 at 2:53 PM, Andrew Maclean<br>
<div><div></div><div class="h5"><<a href="mailto:andrew.amaclean@gmail.com">andrew.amaclean@gmail.com</a>> wrote:<br>
> Dominic,<br>
>   Pat Marion at Kitware found a solution (I am assuming you cannot build<br>
> vtk):<br>
> " It's a CMake + Ubuntu 11.04 issue.  In the latest version of Ubuntu<br>
> (Debian actually) they included multiarch support.  Many libraries are no<br>
> longer located in /usr/lib, now they are in /usr/lib/x86_64-linux-gnu.  This<br>
> causes cmake to fail when it searches for things like X11.<br>
><br>
> To solve this, I edited UnixPaths.cmake in my cmake 2.8.4 install and<br>
> appended the path /usr/lib/x86_64-linux-gnu to the variables<br>
> CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES.<br>
><br>
><br>
> Here is the cmake bug<br>
> report:  <a href="http://public.kitware.com/Bug/view.php?id=12037" target="_blank">http://public.kitware.com/Bug/view.php?id=12037</a> "<br>
> Regards<br>
>    Andrew<br>
> On Tue, Jun 28, 2011 at 10:21 PM, Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
> wrote:<br>
>><br>
>> More debugging:<br>
>><br>
>> I have two twin systems, both with nvidia, both running Ubuntu 11.04.<br>
>> After configuring with:<br>
>><br>
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_TESTING=OFF<br>
>> -DBUILD_SHARED_LIBS=ON -DVTK_USE_TK=OFF -DVTK_WRAP_PYTHON=ON<br>
>> -DVTK_USE_GUISUPPORT=ON -DVTK_USE_QT=ON -DVTK_USE_QVTK=ON<br>
>> -DPYTHON_INCLUDE_DIR=/usr/include/python2.7<br>
>> -DPYTHON_LIBRARY=/usr/lib/<a href="http://libpython2.7.so" target="_blank">libpython2.7.so</a> ~/pack/vtk-5.6.1<br>
>><br>
>> one system will have<br>
>><br>
>> VTK_OPENGL_HAS_OSMESA:BOOL=ON<br>
>><br>
>> in the cache while the other:<br>
>><br>
>> VTK_OPENGL_HAS_OSMESA:BOOL=OFF<br>
>><br>
>> which I guess pretty much determines which one will compile properly<br>
>> and which one not.<br>
>><br>
>> I can not seem to find any way to see OFF in the former case, neither<br>
>> can I see any striking differences in the setup of both systems. Can<br>
>> someone please shed some light how the GL library is probed and why<br>
>> would it force OSMESA to ON?<br>
>><br>
>> Thanks for any hints,<br>
>> Dominik<br>
>><br>
>> On Tue, Jun 28, 2011 at 2:06 PM, Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
>> wrote:<br>
>> > I am sorry to dig out this old topic, but the consequences of this -<br>
>> > never cleared - situations are very distant reaching.<br>
>> ><br>
>> > As originally reported, I can not compile VTK on Ubuntu 11.04 other<br>
>> > way than with OSMesa, else I get the previously reported compile time<br>
>> > error:<br>
>> ><br>
>> > ../../bin/libvtkRendering.so.5.6.1: undefined reference to<br>
>> > `vtkOSOpenGLRenderWindow::New()'<br>
>> ><br>
>> > I have the latest nvidia graphics driver installed so I do not see why<br>
>> > this should be required, but installing libosmesa6-dev package solved<br>
>> > the compilation and allows some of my programs to work, But now one of<br>
>> > them does not start up, segfaulting deep in the system callbacks. The<br>
>> > linker links both GL and OSMesa. I have found experimentally, that<br>
>> > (manually) leaving out OSMesa during linking brings my application<br>
>> > back to life.<br>
>> ><br>
>> > The questions:<br>
>> ><br>
>> > 1) Why does the VTK compilation breaks in the first place, and why is<br>
>> > libosmesa required to solve it<br>
>> > 2) How to disable propagation of -lOSMesa in the linker for projects<br>
>> > using VTK.<br>
>> ><br>
>> > Best regards,<br>
>> > Dominik<br>
>> ><br>
>> ><br>
>> > On Mon, May 23, 2011 at 7:53 AM, Andrew Maclean<br>
>> > <<a href="mailto:andrew.amaclean@gmail.com">andrew.amaclean@gmail.com</a>> wrote:<br>
>> >> Hi Dominic,<br>
>> >>    I can confirm that I have similar behavior in Ubuntu 11.01 for<br>
>> >> 64-bit<br>
>> >> machines. Additionally for me if I turn off USE_TCL I can get a clean<br>
>> >> build,<br>
>> >> however running any of the compiled C++ programs produces no output or<br>
>> >> errors. Running vtkpython on a script also produces no output. The<br>
>> >> OSMESA<br>
>> >> stuff looks to be found Ok however OPENGL_xmesa_INCLUDE_DIR is not<br>
>> >> found.<br>
>> >><br>
>> >> One 64 bit machine was upgraded, th other two machines were fresh<br>
>> >> installs.<br>
>> >> They all have different NVidia cards.<br>
>> >> I have done clean builds using the most recent<br>
>> >> git repository (2011-05-22).<br>
>> >> I have:<br>
>> >> libosmesa6-dev ver<br>
>> >> mesa-common-dev<br>
>> >> libgl1-mesa-dev<br>
>> >> libglu1-mesa-dev<br>
>> >> xlibmesa-gl-dev<br>
>> >> All version 7.10.2. and all installed.<br>
>> >> Interestingly I can download a binary version of ParaView and this runs<br>
>> >> Ok.<br>
>> >> So this is a VTK/Ubuntu 11.4 issue.<br>
>> >> Regards<br>
>> >>    Andrew<br>
>> >><br>
>> >> ---------- Forwarded message ----------<br>
>> >> From: Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
>> >> To: David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>>, VTK users group<br>
>> >> <<a href="mailto:vtkusers@vtk.org">vtkusers@vtk.org</a>><br>
>> >> Date: Sat, 21 May 2011 19:12:03 +0200<br>
>> >> Subject: Re: [vtkusers] undefined reference to<br>
>> >> `vtkOSOpenGLRenderWindow::New()<br>
>> >> Hi David,<br>
>> >><br>
>> >> Many thanks for your input.<br>
>> >><br>
>> >> I confirm that having all the packages that you mentioned I never<br>
>> >> manage to pray VTK_OPENGL_HAS_OSMESA off. Subsequently, I get the<br>
>> >> originally reported compilation error.<br>
>> >> The only way I found to resolve this problem is to additionally<br>
>> >> install libosmesa6-dev and allow VTK_OPENGL_HAS_OSMESA ON. Compiles<br>
>> >> correctly and seems to link to nvidia drivers. Works, but quite<br>
>> >> unexpectedly, and I do feel unrest for the future,<br>
>> >><br>
>> >> Interestingly, on my other Ubuntu 11.04/64 installation this is not<br>
>> >> necessary. /usr/lib/libGL.so points to the same (mesa) lib. It has the<br>
>> >> same version of nvidia driver. The only difference the other machine<br>
>> >> is an upgrade from Ubuntu 10.10, the problematic one is a fresh<br>
>> >> installation. Another difference is that the former machine as an<br>
>> >> older nvidia graphics card (~2 years) known to be supported under<br>
>> >> linux, the problematic one is  much newer (nVidia Corporation G94<br>
>> >> [Quadro FX 1800]).<br>
>> >><br>
>> >> So in an essence, you may want to debug why/if libosmesa6 is needed. I<br>
>> >> am glad to test any patches.<br>
>> >><br>
>> >> Regards,<br>
>> >> Dominik<br>
>> >><br>
>> >> On Sat, May 21, 2011 at 2:49 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>><br>
>> >> wrote:<br>
>> >>> Hi Dominik,<br>
>> >>><br>
>> >>> The directory /usr/lib/nvidia-current is added to run-time library<br>
>> >>> path by the following file:<br>
>> >>><br>
>> >>> /etc/ld.so.conf.d/GL.conf<br>
>> >>><br>
>> >>> This file is part of the nvidia driver installation on 10.04.  So<br>
>> >>> ubuntu uses /usr/lib/libGL.so (which points to mesa) at compile<br>
>> >>> time, but uses /lusr/lib/nvidia-current/libGL.so.1 at run-time.<br>
>> >>><br>
>> >>> It worried me a bit at first, but this setup seems to work fine.<br>
>> >>> It has never caused me problems when compiling VTK.<br>
>> >>><br>
>> >>> So my guess is that you are seeing problems because you are<br>
>> >>> missing an OpenGL devel packages.  Make sure that you have<br>
>> >>> the following installed:<br>
>> >>><br>
>> >>> mesa-common-dev<br>
>> >>> libgl1-mesa-dev<br>
>> >>> libglu1-mesa-dev<br>
>> >>> xlibmesa-gl-dev<br>
>> >>><br>
>> >>> Don't worry that these aren't "nvidia".  The nvidia libs are only<br>
>> >>> used at run-time, not at compile-time.<br>
>> >>><br>
>> >>> Also, just as you have been doing so far, make sure that<br>
>> >>> VTK_OPENGL_HAS_OSMESA is OFF.<br>
>> >>><br>
>> >>>  - David<br>
>> >>><br>
>> >>><br>
>> >>> On Sat, May 21, 2011 at 6:22 AM, Dominik Szczerba<br>
>> >>> <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
>> >>> wrote:<br>
>> >>>> Thanks for your email.<br>
>> >>>><br>
>> >>>> Indeed, initially, I was pointing to the 32 bit nvidia, but pointing<br>
>> >>>> to 64 does not work either.<br>
>> >>>> It keeps saying it switches to OSMESA because no OPENGL_gl_LIBRARY<br>
>> >>>> was<br>
>> >>>> found. /usr/lib/libGL.so is there, but points to mesa/libGL.so, not<br>
>> >>>> nvidia. Changing symlink by hand changes nothing.<br>
>> >>>> Just trying things out blind I have installed libosmesa6 (it was not<br>
>> >>>> installed) and then proceeded with the compilation as if using<br>
>> >>>> software rendering. Compilation was successful, but then:<br>
>> >>>><br>
>> >>>> $ ldd libvtkRendering.so | grep GL<br>
>> >>>>        libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1<br>
>> >>>> (0x00007f7986653000)<br>
>> >>>><br>
>> >>>> comes quite unexpectedly! Great, but there is certainly something<br>
>> >>>> wrong.<br>
>> >>>><br>
>> >>>> My preliminary theory is that cmake fails to detect the otherwise<br>
>> >>>> correct vendor libGL library properly. Does it sound reasonable or<br>
>> >>>> you<br>
>> >>>> have another idea? I feel quite a bit of unrest because of it.<br>
>> >>>><br>
>> >>>> Thanks<br>
>> >>>> Dominik<br>
>> >>>><br>
>> >>>> On Fri, May 20, 2011 at 2:07 PM, Kevin H. Hobbs <<a href="mailto:hobbsk@ohio.edu">hobbsk@ohio.edu</a>><br>
>> >>>> wrote:<br>
>> >>>>> On 05/20/2011 07:41 AM, Dominik Szczerba wrote:<br>
>> >>>>>> I further looked into the problem and I see that cmake is stubborn<br>
>> >>>>>> on<br>
>> >>>>>> this variable: VTK_OPENGL_HAS_OSMESA. It always switches it back<br>
>> >>>>>> on,<br>
>> >>>>>> even if I set it to off. I do have my nvidia driver under<br>
>> >>>>>> /usr/lib32/nvidia-current/libGL.so which I pass as<br>
>> >>>>>> OPENGL_gl_LIBRARY.<br>
>> >>>>>> But it still seems unable to find it. Any ideas?<br>
>> >>>>>><br>
>> >>>>><br>
>> >>>>> Gaaa not enough nervous in caffeine system. I basically ignored<br>
>> >>>>> the second half of your e-mail.<br>
>> >>>>><br>
>> >>>>> "/usr/lib32"  you said you were on 64 bit Ubuntu the linker may<br>
>> >>>>> not be able to use this as the rest of the app. will be 64 bit<br>
>> >>>>> unless you're cross compiling.  Does "-m 32" in CMAKE_CXX_FLAGS<br>
>> >>>>> and CMAKE_C_FLAGS do this?<br>
>> >>><br>
>> >>><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> ___________________________________________<br>
>> >> Andrew J. P. Maclean<br>
>> >> Australian Centre for Field Robotics (ACFR)<br>
>> >> The Rose Street Building J04<br>
>> >> The University of Sydney  2006  NSW<br>
>> >> AUSTRALIA<br>
>> >> Ph: <a href="tel:%2B61%202%209351%203283" value="+61293513283">+61 2 9351 3283</a><br>
>> >> Fax: <a href="tel:%2B61%202%209351%207474" value="+61293517474">+61 2 9351 7474</a><br>
>> >> URL: <a href="http://www.acfr.usyd.edu.au/" target="_blank">http://www.acfr.usyd.edu.au/</a><br>
>> >> ___________________________________________<br>
>> >><br>
>> ><br>
><br>
><br>
><br>
> --<br>
> ___________________________________________<br>
> Andrew J. P. Maclean<br>
> Australian Centre for Field Robotics (ACFR)<br>
> The Rose Street Building J04<br>
> The University of Sydney  2006  NSW<br>
> AUSTRALIA<br>
> Ph: <a href="tel:%2B61%202%209351%203283" value="+61293513283">+61 2 9351 3283</a><br>
> Fax: <a href="tel:%2B61%202%209351%207474" value="+61293517474">+61 2 9351 7474</a><br>
> URL: <a href="http://www.acfr.usyd.edu.au/" target="_blank">http://www.acfr.usyd.edu.au/</a><br>
> ___________________________________________<br>
><br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtkusers" target="_blank">http://www.vtk.org/mailman/listinfo/vtkusers</a><br>
</div></div></blockquote></div><br>