[vtkusers] undefined reference to `vtkOSOpenGLRenderWindow::New()

Tue Jun 28 12:02:37 EDT 2011

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.

Pat

On Tue, Jun 28, 2011 at 9:10 AM, Dominik Szczerba <dominik at itis.ethz.ch>wrote:

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