Thread for errata and requests-to-nvidia?

Is it useful to have a thread here to report errata which may indicate a need for NVIDIA staff to repair?

For example: First, I followed the CUDA installation instructions and built all of the examples. They all built and all work with excellent speed and detail in display.

Trying to build OpenSceneGraph. Pulled the repository with

svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2.0

When following instructions for the cmake a lot of unsatisfied dependencies showed up.

Rather than resolve the dependencies with apt-get install <package>, I am building any X/GL-ish dependencies from source. The idea is that everything I build will link against the NVIDIA-provided packages installed from CUDA. So far, this mostly works.

But here’s something that apt-get -b source <packages cannot solve.

trimmed …
dpkg-shlibdeps: error: no dependency information found for /usr/lib/arm-linux-gnueabihf/tegra/libGL.so.1 (used by debian/libgtkglext1/usr/lib/libgdkglext-x11-1.0.so.0.0.0)
… trimmed

Thus, building ubuntu package “gtkglext-1.2.0” from source failed. I think that the NVIDIA packagers may need to build a package with more dependency information? Alternatively, if this is not needed, perhaps some helpful hints or workaround?

Meanwhile I am forcing a build using the “-d” (don’t check dependencies) flag to dpkg-buildpackage. This may be a way to get my project done but could make for difficult debugging in dependency tracking going forward.

I guess this has something to do with nvidia’s closed source binary drivers.
Workaround is described here: http://forums.linuxmint.com/viewtopic.php?f=208&t=113890

You shouldn’t need to compile explicitly against NVIDIA’s libGL, needing to do that would break every Linux distro out there.

Basically you should compile against any libGL (like the Mesa) and when you launch the application, the run-time linker will find the platform specific libGL (e.g. NVIDIA) to load.

If you do want change and compile some package you will still bump into the same missing dependency information issue. I don’t know if there’s solution for all packages but either you can temporarily disable /usr/lib/arm-linux-gnueabihf/ so that the build system finds only the “generic” libGL.so.1 or you can add a .shlibs file inwhich you can explicitly say what to use instead of the Tegra specific libGL. See e.g.:

Thank you both. This helps a lot to increase the level of automation. I was just changing into the directory and running ‘dpkg-shlibdeps’ adding the flag by hand.

It doesn’t seem to matter to my particular bottleneck. At the moment this is a well-documented problem with QT including a couple of GL-related files putting a compile of incompatible defines into overlapping symbol space, if I am understanding it correctly. I haven’t yet found a fix, though I am trying right now with a newly-released package set which includes QT5, and the bleeding-edge version of OpenSceneGraph. The QT-related issue is the main problem there and is known to have been a problem in compiling against both QT4 and GL dating back to 2012 or so.

(LATER: the new package set including QT5 allows a full compile with no obvious errors and with no errors requiring intervention or workaround.)

I should add that now I seem to have FreeGLUT/OpenGL includes in a few places now, the CUDA-package provided stuff in one place and others where you would expect them. For example glext.h is found in both these places. I guess I need to pick which ones I need at the time I need them with a little Makefile hackery of -I and -L. Here they are. ;)

/usr/include/GL/glext.h
/usr/local/cuda-6.0/extras/CUPTI/include/GL/glext.h

I’m not sure if I should be creating a lot of symlinks (which has been suggested) or just pick and choose with flags in Makefile. The latter is more work but less likely to cause breakage later on.

Thanks again to all,