Dominic,<div> Pat Marion at Kitware found a solution (I am assuming you cannot build vtk):</div><div><span style="border-collapse:collapse;color:rgb(34, 34, 34);font-family:arial, sans-serif;font-size:13px">" It's a CMake + Ubuntu 11.04 issue. In the latest version of Ubuntu (Debian actually) they included multiarch support. Many libraries are no longer located in /usr/lib, now they are in /usr/lib/x86_64-linux-gnu. This 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 appended the path /usr/lib/x86_64-linux-gnu to the variables CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES.<br><br></span><span style="border-collapse:collapse;color:rgb(34, 34, 34);font-family:arial, sans-serif;font-size:13px"><br>
Here is the cmake bug report: <a href="http://public.kitware.com/Bug/view.php?id=12037" style="color:rgb(53, 66, 88)" target="_blank">http://public.<span style="background-color:rgb(255, 189, 93);color:rgb(34, 34, 34);background-repeat:initial initial">kitware</span>.com/Bug/view.php?id=12037</a> " </span></div>
<div><br></div><div>Regards</div><div> Andrew</div><div><br><div class="gmail_quote">On Tue, Jun 28, 2011 at 10:21 PM, Dominik Szczerba <span dir="ltr"><<a href="mailto:dominik@itis.ethz.ch" target="_blank">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">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>
<font color="#888888">Dominik<br>
</font><div><div></div><div><br>
On Tue, Jun 28, 2011 at 2:06 PM, Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch" target="_blank">dominik@itis.ethz.ch</a>> 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 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" target="_blank">andrew.amaclean@gmail.com</a>> wrote:<br>
>> Hi Dominic,<br>
>> I can confirm that I have similar behavior in Ubuntu 11.01 for 64-bit<br>
>> machines. Additionally for me if I turn off USE_TCL I can get a clean 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 OSMESA<br>
>> stuff looks to be found Ok however OPENGL_xmesa_INCLUDE_DIR is not found.<br>
>><br>
>> One 64 bit machine was upgraded, th other two machines were fresh installs.<br>
>> They all have different NVidia cards.<br>
>> I have done clean builds using the most recent 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 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" target="_blank">dominik@itis.ethz.ch</a>><br>
>> To: David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>>, VTK users group <<a href="mailto:vtkusers@vtk.org" target="_blank">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" target="_blank">david.gobbi@gmail.com</a>> 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 <<a href="mailto:dominik@itis.ethz.ch" target="_blank">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 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 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 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" target="_blank">hobbsk@ohio.edu</a>> 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 on<br>
>>>>>> this variable: VTK_OPENGL_HAS_OSMESA. It always switches it back 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 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" target="_blank">+61 2 9351 3283</a><br>
>> Fax: <a href="tel:%2B61%202%209351%207474" value="+61293517474" target="_blank">+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>
</div></div></blockquote></div><br><br clear="all"><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" target="_blank">+61 2 9351 3283</a><br>Fax: <a href="tel:%2B61%202%209351%207474" value="+61293517474" target="_blank">+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>
</div>