Hey all,
I changed from nvidia's binary driver to the one in the etch repo (8776). Gem compiles (anon cvs update from today), but PD wont load it:
/usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: glUniform2i
I've removed the files from the provided-by-nvidia-driver (--uninstall)
Could there still be some headers somewhere and its compiling against the wrong opengl stuff?
bbogart@insitu:~$ dpkg -l "*nvidia*" | grep ^ii ii nvidia-glx 1.0.8776-3 NVIDIA binary XFree86 4.x driver ii nvidia-kernel-2.6.18-3-686 1.0.8776-3+2.6.18-7 NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-common 20051028+1 NVIDIA binary kernel module common files ii nvidia-kernel-source 1.0.8776-3 NVIDIA binary kernel module source ii nvidia-settings 1.0+20060516-3 Tool of configuring the NVIDIA graphics driv
I'm lost, any suggestions?
Attached is my config.log if that helps.
Thanks, .b.
On 1/26/07, B. Bogart ben@ekran.org wrote:
Hey all,
I changed from nvidia's binary driver to the one in the etch repo (8776).
Why? Only the Nvidia binary actually uses the GPU for rendering.
Gem compiles (anon cvs update from today), but PD wont load it:
/usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: glUniform2i
This was covered in the two previous postings to this list. You need non busted drivers with OpenGL 2.0 support. The NV binaries certainly work.
blech.
Why? cause when I update things break, when I use the stuff in repos, stuff breaks less often when I update.
This time X refused to load the newest nvidia driver, probably because the location that X in etch expects modules is different than the place nvidia puts em. I did not investigate further.
Note the driver from the repo *IS* the nvidia binary, 1.0-8776, a little old, but I see no reason it would work any differently than the 1.0-8776 driver from nvidia's website.
I think debian just makes a deb for the nvidia stuff, without changing it.
If nvidia's latest driver "just worked" as it used to, I'd be using it. But alas its doing something wrong from the eyes of my debian/etch machine, and I doubt that is the problem in the first place, though I guess I should figure out why the thing does not work on my machine... if only there was more time.
.b.
chris clepper wrote:
On 1/26/07, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
Hey all, I changed from nvidia's binary driver to the one in the etch repo (8776).Why? Only the Nvidia binary actually uses the GPU for rendering.
Gem compiles (anon cvs update from today), but PD wont load it: /usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: glUniform2iThis was covered in the two previous postings to this list. You need non busted drivers with OpenGL 2.0 support. The NV binaries certainly work.
I had to use an extra flag on the nvidia installer to get it to put the stuff in the right places. Working fine now.
So to be clear, what is the minimum version of the nvidia drivers that works with the GLSL stuff? (1.0-9000?)
Thanks.
.b.
B. Bogart wrote:
blech.
Why? cause when I update things break, when I use the stuff in repos, stuff breaks less often when I update.
This time X refused to load the newest nvidia driver, probably because the location that X in etch expects modules is different than the place nvidia puts em. I did not investigate further.
Note the driver from the repo *IS* the nvidia binary, 1.0-8776, a little old, but I see no reason it would work any differently than the 1.0-8776 driver from nvidia's website.
I think debian just makes a deb for the nvidia stuff, without changing it.
If nvidia's latest driver "just worked" as it used to, I'd be using it. But alas its doing something wrong from the eyes of my debian/etch machine, and I doubt that is the problem in the first place, though I guess I should figure out why the thing does not work on my machine... if only there was more time.
.b.
chris clepper wrote:
On 1/26/07, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
Hey all, I changed from nvidia's binary driver to the one in the etch repo (8776).Why? Only the Nvidia binary actually uses the GPU for rendering.
Gem compiles (anon cvs update from today), but PD wont load it: /usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: glUniform2iThis was covered in the two previous postings to this list. You need non busted drivers with OpenGL 2.0 support. The NV binaries certainly work.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 1/26/07, B. Bogart ben@ekran.org wrote:
I had to use an extra flag on the nvidia installer to get it to put the stuff in the right places. Working fine now.
So to be clear, what is the minimum version of the nvidia drivers that works with the GLSL stuff? (1.0-9000?)
Nvidia have had support for GLSL for years.
hmmm, then 1.0-8776 should have worked...
maybe a bug in the particular version that debian packages.
Happy its working at all.
The cool thing about having a fast machine around is that damn its fast!!! (I like to keep using my old machines to keep my ideas realalistic, as long as the 1.25Ghz g4 w/9600 feels fast I should be happy) - which makes my AMD64 fly like crazy!!! My old feedback patches barely move the CPU monitor!
.b.
chris clepper wrote:
On 1/26/07, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
I had to use an extra flag on the nvidia installer to get it to put the stuff in the right places. Working fine now. So to be clear, what is the minimum version of the nvidia drivers that works with the GLSL stuff? ( 1.0-9000?)Nvidia have had support for GLSL for years.
Johannes, have any ideas on this? I'm stuck and not sure what to do next.
B. Bogart
B. Bogart wrote:
hmmm, then 1.0-8776 should have worked...
maybe a bug in the particular version that debian packages.
Happy its working at all.
The cool thing about having a fast machine around is that damn its fast!!! (I like to keep using my old machines to keep my ideas realalistic, as long as the 1.25Ghz g4 w/9600 feels fast I should be happy) - which makes my AMD64 fly like crazy!!! My old feedback patches barely move the CPU monitor!
.b.
chris clepper wrote:
On 1/26/07, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
I had to use an extra flag on the nvidia installer to get it to put the stuff in the right places. Working fine now. So to be clear, what is the minimum version of the nvidia drivers that works with the GLSL stuff? ( 1.0-9000?)Nvidia have had support for GLSL for years.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Alright, it was solved by purging nvidia-glx and removing those files the purge choked on. I suppose all the crap floating in my system is due to overuse of the nvidia provided installers... At last I am free! (at least of nvidia's .run)
Now if only Gem would work with DRI...
.b.
IOhannes m zmoelnig wrote:
B. Bogart wrote:
Johannes, have any ideas on this? I'm stuck and not sure what to do next.
no not really; i'll have to go through this thread again but i am running the Gem-cvs just fine on a debian/etch installation (nvidia-glx is 1.0.8776-4)
mfg.asdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hey all,
I've now got time to revisit this issue.
#1. I've changed to the (binary blob from nvidia) that is included in the non-free repos because I'm tired of the stupid manual installation that needs to be done every time I update a machine. I must have run that *$#%*#$ installer 100 times and wasted hours of my life. So I switched to the one in the repo that will just work with debian out of the box. Only issue is its a slightly older version (87xx) rather than (97xx) but I was using gem user the 87xx series for ages without issues.
I have not had any issues with those older drivers, and in fact before I gave up the annoyance of the nvidia installer I was using the very same driver version, just through the manual installer.
so to clarify I *AM* using the nvidia binary driver, just the ones made debian friendly in their repos:
http://packages.debian.org/testing/x11/nvidia-glx-dev
which provides all this stuff:
/. /usr /usr/bin /usr/bin/nvidia-bug-report.sh /usr/lib /usr/lib/xorg /usr/lib/xorg/modules /usr/lib/xorg/modules/drivers /usr/lib/xorg/modules/drivers/nvidia_drv.o /usr/lib/xorg/modules/extensions /usr/lib/xorg/modules/extensions/libglx.so.1.0.8776 /usr/lib/tls /usr/lib/nvidia /usr/lib/nvidia/libnvidia-tls.so.1.0.8776 /usr/lib/nvidia/libnvidia-cfg.so.1.0.8776 /usr/lib/nvidia/tls_test /usr/lib/nvidia/tls_test_dso.so /usr/lib/libXvMCNVIDIA.so.1.0.8776 /usr/lib/libGL.so.1.0.8776 /usr/lib/libGLcore.so.1.0.8776 /usr/lib/libnvidia-tls.so.1.0.8776 /usr/share /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/nvidia-glx /usr/share/bug /usr/share/bug/nvidia-glx /usr/share/bug/nvidia-glx/script /usr/share/doc /usr/share/doc/nvidia-glx /usr/share/doc/nvidia-glx/README.Debian /usr/share/doc/nvidia-glx/copyright /usr/share/doc/nvidia-glx/examples /usr/share/doc/nvidia-glx/examples/XF86Config.sample.gz /usr/share/doc/nvidia-glx/changelog.Debian.gz /usr/share/doc/nvidia-glx/NEWS.Debian.gz /usr/share/doc/nvidia-glx/NVIDIA_Changelog.gz /usr/share/doc/nvidia-glx/README.txt.gz /etc /etc/default /etc/default/nvidia-glx /etc/init.d /etc/init.d/nvidia-glx /usr/lib/xorg/modules/extensions/libglx.so package diverts others to: /usr/lib/nvidia/libglx.so.xlibmesa /usr/lib/libXvMCNVIDIA_dynamic.so.1 /usr/lib/libXvMCNVIDIA.so.1 /usr/lib/libnvidia-tls.so.1 /usr/lib/libGLcore.so.1 /usr/lib/libGL.so.1 package diverts others to: /usr/lib/nvidia/libGL.so.1.xlibmesa
I confirmed that the GL headers I'm compiling against are provided by nvidia, not mesa:
glext.h:
#ifndef __glext_h_ #define __glext_h_
#ifdef __cplusplus extern "C" { #endif
/******************************************************************************
Copyright NVIDIA Corporation 2005 ...
and glext.h does include glUniform2i:
GLAPI void APIENTRY glUniform2i (GLint, GLint, GLint);
I'm sure I'm compiling against those headers, because they are located in /usr/include/GL and the mesa headers have been renamed.
I can see that glext.h provides the declaration for glUniform2i, but what library is supposed to contain that symbol? nm says all the nvidia provided libs "contain no symbols"
too add insult to injury I have GEM working on an almost identical machine at school with the same version of the nvidia driver from the debian repo. If I try and load the binary built on that machine here I get glUniform4iARB is unresolved. (which is defined in the same glext.h header (the same one on both machines also)
So it seams the binaries are not inline with the headers, so I have to figure out what is different about the two machines. (in terms of GL binary libs) after another hour of digging I can't tell what is the difference between the two machines, my machine has /usr/lib/libGL.a (which is supposedly provided by a debian package that I don't have installed) but renaming it made no difference.
I've attached my ./configure from both machines, which are pretty well identical. And here are the GL packages installed on both:
bbogart@sr-01499:~$ dpkg -l "*mesa*" | grep ^ii ii libgl1-mesa-dri 6.5.1-0.6 A free implementation of the OpenGL API -- D ii libgl1-mesa-glx 6.5.1-0.6 A free implementation of the OpenGL API -- G ii libglu1-mesa 6.5.1-0.6 The OpenGL utility library (GLU) ii libglu1-mesa-dev 6.5.1-0.6 The OpenGL utility library -- development su ii mesa-utils 6.3.2-2.1 Miscellaneous Mesa GL utilities
bbogart@insitu:~$ dpkg -l "*mesa*" | grep ^ii ii libgl1-mesa-dri 6.5.1-0.6 A free implementation of the OpenGL API -- D ii libgl1-mesa-glx 6.5.1-0.6 A free implementation of the OpenGL API -- G ii libglu1-mesa 6.5.1-0.6 The OpenGL utility library (GLU) ii libglu1-mesa-dev 6.5.1-0.6 The OpenGL utility library -- development su ii mesa-utils 6.3.2-2.1 Miscellaneous Mesa GL utilities
bbogart@sr-01499:~$ dpkg -l "*nvidia*" | grep ^ii ii nvidia-glx 1.0.8776-4 NVIDIA binary XFree86 4.x driver ii nvidia-glx-dev 1.0.8776-4 NVIDIA binary XFree86 4.x / Xorg driver deve ii nvidia-kernel-2.6.18-4-486 1.0.8776+6 NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-2.6.18-4-686 1.0.8776+6 NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-common 20051028+1 NVIDIA binary kernel module common files ii nvidia-settings 1.0+20060516-3 Tool of configuring the NVIDIA graphics driv
bbogart@insitu:~$ dpkg -l "*nvidia*" | grep ^ii ii nvidia-glx 1.0.8776-4 NVIDIA binary XFree86 4.x driver ii nvidia-glx-dev 1.0.8776-4 NVIDIA binary XFree86 4.x / Xorg driver deve ii nvidia-kernel-2.6.18-4-686 1.0.8776+6 NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-common 20051028+1 NVIDIA binary kernel module common files ii nvidia-kernel-source 1.0.8776-4 NVIDIA binary kernel module source
both machines are up to date etch's as of today...
I don't get it...
.b.
chris clepper wrote:
On 1/26/07, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
Hey all, I changed from nvidia's binary driver to the one in the etch repo (8776).Why? Only the Nvidia binary actually uses the GPU for rendering.
Gem compiles (anon cvs update from today), but PD wont load it: /usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: glUniform2iThis was covered in the two previous postings to this list. You need non busted drivers with OpenGL 2.0 support. The NV binaries certainly work.
checking for Base/configLinux.h.in... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking whether compiler accepts "-fPIC"... yes building Gem with Controls-objects building Gem with Geos-objects building Gem with Manips-objects building Gem with Nongeos-objects building Gem with Particles-objects building Gem with Pixes-objects building Gem with openGL-objects building Gem without Vertex-objects checking for sin in -lm... yes checking for main in -lz... yes checking for dlopen in -ldl... yes checking how to run the C++ preprocessor... g++ -E checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for main in -lX11... yes checking for main in -lXext... yes checking for XF86VidModeGetAllModeLines in -lXxf86vm... no checking for main in -lXext... (cached) yes checking for "OpenGL"-framework... no checking for glInitNames in -lGL... yes checking for gluLookAt in -lGLU... yes checking for "AGL"-framework... no checking for "Carbon"-framework... no checking for "QuickTime"-framework... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PKG_TIFF_CFLAGS... checking for PKG_TIFF_LIBS... checking for tiff-config... no checking for TIFFOpen in -ltiff... yes checking for PKG_JPEG_CFLAGS... checking for PKG_JPEG_LIBS... checking for jpeg-config... no checking for jpeg_read_header in -ljpeg... yes checking for PKG_LIBQUICKTIME_CFLAGS... -I/usr/include/lqt checking for PKG_LIBQUICKTIME_LIBS... -lquicktime -lpthread -lm -lz -ldl checking for PKG_LQT_CFLAGS... checking for PKG_LQT_LIBS... checking for lqt-config... yes checking for PKG_MPEG3_CFLAGS... checking for PKG_MPEG3_LIBS... checking for mpeg3-config... no checking for mpeg3_check_sig in -lmpeg3... yes checking for PKG_MPEG_CFLAGS... checking for PKG_MPEG_LIBS... checking for mpeg-config... no checking for OpenMPEG in -lmpeg... no checking for PKG_AVIFILE_CFLAGS... -I/usr/include/avifile-0.7 checking for PKG_AVIFILE_LIBS... -laviplay checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking linux/videodev.h usability... yes checking linux/videodev.h presence... yes checking for linux/videodev.h... yes checking for PKG_IEEE1394_CFLAGS... checking for PKG_IEEE1394_LIBS... checking for ieee1394-config... no checking for main in -ldv... yes checking whether linker accepts "-lGLU -lGL -lfreetype -lz -lftgl_pic "... yes checking for PKG_FTGL_CFLAGS... -I/usr/include/FTGL -I/usr/include/freetype2 checking for PKG_FTGL_LIBS... -lGLU -lGL -lfreetype -lz -lftgl_pic checking for PKG_ARTOOLKIT_CFLAGS... checking for PKG_ARTOOLKIT_LIBS... checking for artoolkit-config... no checking for arInitCparam in -lAR... no checking for pthread_create in -lpthread... yes checking for X... libraries , headers checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for memory.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... no checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for GLsizeiptrARB... yes checking for unsigned int... yes checking size of unsigned int... 4 checking for void *... yes checking size of void *... 4 checking for error_at_line... yes checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for bzero... yes checking for floor... yes checking for gettimeofday... yes checking for memset... yes checking for munmap... yes checking for pow... yes checking for sqrt... yes checking for strchr... yes checking for strdup... yes checking for strrchr... yes checking for strstr... yes checking for lqt_add_video_track... yes checking for glBindProgramARB... yes checking for glBindProgramNV... yes checking m_pd.h usability... yes checking m_pd.h presence... yes checking for m_pd.h... yes checking whether compiler accepts "-freg-struct-return"... yes enabling "register struct return" allows to make use of FreeFrame-effects without recompiling them might break things, if you are using several different compilers checking whether compiler accepts "-O3"... yes checking whether compiler accepts "-falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops"... yes checking whether compiler accepts "-ffast-math"... yes checking whether compiler accepts "-mmmx"... yes checking whether compiler accepts "-msse2"... yes checking whether compiler accepts "-fpascal-strings"... no checking whether linker accepts "-shared -Wl,-export-dynamic"... yes checking whether linker accepts "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup"... no checking whether linker accepts "-bundle -undefined suppress -flat_namespace"... no checking for strip... strip checking if strip is GNU strip... yes checking for dos2unix... no configure: creating ./config.status config.status: creating Make.config config.status: creating Base/configLinux.h
Result: Target : Gem.pd_linux Objects : Base Controls Geos Manips Nongeos Particles Pixes openGL
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math -mmmx -msse2 : -I/usr/include/lqt -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/include/FTGL -I/usr/include/freetype2 INCLUDES : -I/usr/include/FTGL -I/usr/include/freetype2 DEFINES :
LIBS : -ldv -lmpeg3 -ljpeg -ltiff -lGLU -lGL -lXext -lXext -lX11 -ldl -lz -lm -lpthread : -lGLU -lGL -lfreetype -lz -lftgl_pic -laviplay -L/usr/lib -lquicktime -lpthread -lm -lz -ldl -lquicktime -lpthread -lm -lz -ldl LDFLAGS : -shared -Wl,-export-dynamic -lGLU -lGL -lfreetype -lz -lftgl_pic :
Strip : strip --strip-unneeded
Install path : /usr/
pure-data: version : 0.39
openGL : using version : (default) using ARB-extensions : yes using NV-extensions : yes
used optional libraries:
font-rendering : FTGL
image-support use ImageMagick : no (forced) use TIFF : yes use JPEG : yes video-support use mpeg : no use mpeg-3 : yes use QuickTime : yes use aviplay : yes use ffmpeg : no (forced) input-support use v4l : yes use ieee1394 : yes
misc using ARB-extensions : yes
Now run make ...
checking for Base/configLinux.h.in... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking whether compiler accepts "-fPIC"... yes building Gem with Controls-objects building Gem with Geos-objects building Gem with Manips-objects building Gem with Nongeos-objects building Gem with Particles-objects building Gem with Pixes-objects building Gem with openGL-objects building Gem without Vertex-objects checking for sin in -lm... yes checking for main in -lz... yes checking for dlopen in -ldl... yes checking how to run the C++ preprocessor... g++ -E checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for main in -lX11... yes checking for main in -lXext... yes checking for XF86VidModeGetAllModeLines in -lXxf86vm... yes checking for main in -lXext... (cached) yes checking for "OpenGL"-framework... no checking for glInitNames in -lGL... yes checking for gluLookAt in -lGLU... yes checking for "AGL"-framework... no checking for "Carbon"-framework... no checking for "QuickTime"-framework... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PKG_TIFF_CFLAGS... checking for PKG_TIFF_LIBS... checking for tiff-config... no checking for TIFFOpen in -ltiff... yes checking for PKG_JPEG_CFLAGS... checking for PKG_JPEG_LIBS... checking for jpeg-config... no checking for jpeg_read_header in -ljpeg... yes checking for PKG_LIBQUICKTIME_CFLAGS... -I/usr/include/lqt checking for PKG_LIBQUICKTIME_LIBS... -lquicktime -lpthread -lm -lz -ldl checking for PKG_LQT_CFLAGS... checking for PKG_LQT_LIBS... checking for lqt-config... yes checking for PKG_MPEG3_CFLAGS... checking for PKG_MPEG3_LIBS... checking for mpeg3-config... no checking for mpeg3_check_sig in -lmpeg3... yes checking for PKG_MPEG_CFLAGS... checking for PKG_MPEG_LIBS... checking for mpeg-config... no checking for OpenMPEG in -lmpeg... yes checking for PKG_AVIFILE_CFLAGS... -I/usr/include/avifile-0.7 checking for PKG_AVIFILE_LIBS... -laviplay checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking linux/videodev.h usability... yes checking linux/videodev.h presence... yes checking for linux/videodev.h... yes checking for PKG_IEEE1394_CFLAGS... checking for PKG_IEEE1394_LIBS... checking for ieee1394-config... no checking for main in -ldv... yes checking whether linker accepts "-lGLU -lGL -lfreetype -lz -lftgl_pic "... yes checking for PKG_FTGL_CFLAGS... -I/usr/include/FTGL -I/usr/include/freetype2 checking for PKG_FTGL_LIBS... -lGLU -lGL -lfreetype -lz -lftgl_pic checking for PKG_ARTOOLKIT_CFLAGS... checking for PKG_ARTOOLKIT_LIBS... checking for artoolkit-config... no checking for arInitCparam in -lAR... no checking for pthread_create in -lpthread... yes checking for X... libraries , headers checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for memory.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... no checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for GLsizeiptrARB... yes checking for unsigned int... yes checking size of unsigned int... 4 checking for void *... yes checking size of void *... 4 checking for error_at_line... yes checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for bzero... yes checking for floor... yes checking for gettimeofday... yes checking for memset... yes checking for munmap... yes checking for pow... yes checking for sqrt... yes checking for strchr... yes checking for strdup... yes checking for strrchr... yes checking for strstr... yes checking for lqt_add_video_track... yes checking for glBindProgramARB... yes checking for glBindProgramNV... yes checking m_pd.h usability... yes checking m_pd.h presence... yes checking for m_pd.h... yes checking whether compiler accepts "-freg-struct-return"... yes enabling "register struct return" allows to make use of FreeFrame-effects without recompiling them might break things, if you are using several different compilers checking whether compiler accepts "-O3"... yes checking whether compiler accepts "-falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops"... yes checking whether compiler accepts "-ffast-math"... yes checking whether compiler accepts "-mmmx"... yes checking whether compiler accepts "-msse2"... yes checking whether compiler accepts "-fpascal-strings"... no checking whether linker accepts "-shared -Wl,-export-dynamic"... yes checking whether linker accepts "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup"... no checking whether linker accepts "-bundle -undefined suppress -flat_namespace"... no checking for strip... strip checking if strip is GNU strip... yes checking for dos2unix... no configure: creating ./config.status config.status: creating Make.config config.status: creating Base/configLinux.h config.status: Base/configLinux.h is unchanged
Result: Target : Gem.pd_linux Objects : Base Controls Geos Manips Nongeos Particles Pixes openGL
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math -mmmx -msse2 : -I/usr/include/lqt -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/include/FTGL -I/usr/include/freetype2 INCLUDES : -I/usr/include/FTGL -I/usr/include/freetype2 DEFINES :
LIBS : -ldv -lmpeg -lmpeg3 -ljpeg -ltiff -lGLU -lGL -lXext -lXxf86vm -lXext -lX11 -ldl -lz -lm -lpthread : -lGLU -lGL -lfreetype -lz -lftgl_pic -laviplay -L/usr/lib -lquicktime -lpthread -lm -lz -ldl -lquicktime -lpthread -lm -lz -ldl LDFLAGS : -shared -Wl,-export-dynamic -lGLU -lGL -lfreetype -lz -lftgl_pic :
Strip : strip --strip-unneeded
Install path : /usr/
pure-data: version : 0.39
openGL : using version : (default) using ARB-extensions : yes using NV-extensions : yes
used optional libraries:
font-rendering : FTGL
image-support use ImageMagick : no (forced) use TIFF : yes use JPEG : yes video-support use mpeg : yes use mpeg-3 : yes use QuickTime : yes use aviplay : yes use ffmpeg : no (forced) input-support use v4l : yes use ieee1394 : yes
misc using ARB-extensions : yes
Now run make ...
hi
B. Bogart wrote:
Hey all,
I've now got time to revisit this issue.
#1. I've changed to the (binary blob from nvidia) that is included in the non-free repos because I'm tired of the stupid manual installation that needs to be done every time I update a machine. I must have run that *$#%*#$ installer 100 times and wasted hours of my life. So I switched to the one in the repo that will just work with debian out of the box. Only issue is its a slightly older version (87xx) rather than (97xx) but I was using gem user the 87xx series for ages without issues.
i am using the 8776 from the debian repository too (though i have a mixed stable/unstable system, but the packages installed are really 1.0.8776-4). no problems here.
so to clarify I *AM* using the nvidia binary driver, just the ones made debian friendly in their repos:
are you sure?
I confirmed that the GL headers I'm compiling against are provided by nvidia, not mesa:
glext.h:
#ifndef __glext_h_ #define __glext_h_
#ifdef __cplusplus
and glext.h does include glUniform2i:
GLAPI void APIENTRY glUniform2i (GLint, GLint, GLint);
which is basically your problem: if the headers define glUniform2i but the library does not, then you get that error.
I'm sure I'm compiling against those headers, because they are located in /usr/include/GL and the mesa headers have been renamed.
I can see that glext.h provides the declaration for glUniform2i, but what library is supposed to contain that symbol? nm says all the nvidia provided libs "contain no symbols"
i am not so firm with advanced things like "nm", but when i do "grep glUniform2i /usr/lib/libGL.so" i get "Binary file /usr/lib/libGL.so matches"
too add insult to injury I have GEM working on an almost identical machine at school with the same version of the nvidia driver from the debian repo. If I try and load the binary built on that machine here I get glUniform4iARB is unresolved. (which is defined in the same glext.h header (the same one on both machines also)
So it seams the binaries are not inline with the headers, so I have to figure out what is different about the two machines. (in terms of GL binary libs) after another hour of digging I can't tell what is the difference between the two machines, my machine has /usr/lib/libGL.a (which is supposedly provided by a debian package that I don't have installed) but renaming it made no difference.
you should NOT have a libGL.a; the thing about using openGL hardware- and software- rendering on demand is about using dynamic libraries.
I've attached my ./configure from both machines, which are pretty well identical. And here are the GL packages installed on both:
i haven't looked through these (yet).
i do believe that you are linking against the wrong openGL library.
run "ldd Gem.pd_linux" if you see that it is linking against /usr/local/lib/libGL.so then you should remove these...
hope this helps
mfgas IOhannes
Thanks Johannes for the reply,
Good to know your running a similar setup, so hopefully this is easily solved.
so indeed Gem was using a GL library in /usr/X11R6/lib/libGL.so.1 (again no idea where it came from, no packages accept responsibility) so I renamed that and recompiled Gem, now LDD shows the proper libGL:
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7c59000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7bef000
LibGL is provided by nvidia-glx:
bbogart@insitu:/usr/lib$ dpkg -L nvidia-glx | grep libGL /usr/lib/libGL.so.1.0.8776 /usr/lib/libGLcore.so.1.0.8776 /usr/lib/libGLcore.so.1 /usr/lib/libGL.so.1 package diverts others to: /usr/lib/nvidia/libGL.so.1.xlibmesa
And my mesa libs seem to be properly diverted by nvidia-glx:
bbogart@insitu:/usr/lib$ dpkg -L libgl1-mesa-glx | grep libGL /usr/lib/libGL.so.1.2 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa /usr/lib/libGL.so.1 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa
libGLU is provided by mesa though, could it me an interaction between mesa GLU and nvidia GLX? Can I disable glu in the gem-build to test that idea?
According to the debian repo the GLU lib is provided only by mesa... no nvidia equivalent.
using grep gives me the same result, so the library should also contain glUniform2i:
bbogart@insitu:~/pd-stuff/cvs/Gem/src$ grep glUniform2i /usr/lib/libGL.so Binary file /usr/lib/libGL.so matches
So it should work, but I'm still getting the unresolved symbol error, any other ideas?
.b.
IOhannes m zmoelnig wrote:
hi
B. Bogart wrote:
Hey all,
I've now got time to revisit this issue.
#1. I've changed to the (binary blob from nvidia) that is included in the non-free repos because I'm tired of the stupid manual installation that needs to be done every time I update a machine. I must have run that *$#%*#$ installer 100 times and wasted hours of my life. So I switched to the one in the repo that will just work with debian out of the box. Only issue is its a slightly older version (87xx) rather than (97xx) but I was using gem user the 87xx series for ages without issues.
i am using the 8776 from the debian repository too (though i have a mixed stable/unstable system, but the packages installed are really 1.0.8776-4). no problems here.
so to clarify I *AM* using the nvidia binary driver, just the ones made debian friendly in their repos:
are you sure?
I confirmed that the GL headers I'm compiling against are provided by nvidia, not mesa:
glext.h:
#ifndef __glext_h_ #define __glext_h_
#ifdef __cplusplus
and glext.h does include glUniform2i:
GLAPI void APIENTRY glUniform2i (GLint, GLint, GLint);
which is basically your problem: if the headers define glUniform2i but the library does not, then you get that error.
I'm sure I'm compiling against those headers, because they are located in /usr/include/GL and the mesa headers have been renamed.
I can see that glext.h provides the declaration for glUniform2i, but what library is supposed to contain that symbol? nm says all the nvidia provided libs "contain no symbols"
i am not so firm with advanced things like "nm", but when i do "grep glUniform2i /usr/lib/libGL.so" i get "Binary file /usr/lib/libGL.so matches"
too add insult to injury I have GEM working on an almost identical machine at school with the same version of the nvidia driver from the debian repo. If I try and load the binary built on that machine here I get glUniform4iARB is unresolved. (which is defined in the same glext.h header (the same one on both machines also)
So it seams the binaries are not inline with the headers, so I have to figure out what is different about the two machines. (in terms of GL binary libs) after another hour of digging I can't tell what is the difference between the two machines, my machine has /usr/lib/libGL.a (which is supposedly provided by a debian package that I don't have installed) but renaming it made no difference.
you should NOT have a libGL.a; the thing about using openGL hardware- and software- rendering on demand is about using dynamic libraries.
I've attached my ./configure from both machines, which are pretty well identical. And here are the GL packages installed on both:
i haven't looked through these (yet).
i do believe that you are linking against the wrong openGL library.
run "ldd Gem.pd_linux" if you see that it is linking against /usr/local/lib/libGL.so then you should remove these...
hope this helps
mfgas IOhannes
Hi all,
So I'm looking at this again, I had a /usr/X11R6 folder laying around, I suppose the switch from xfree to xorg did not go as smoothly as it looked.
Anyhow I'm now compiling against:
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7c4e000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7be4000)
which are provided by nvidia-glx:
% dpkg -L nvidia-glx /usr/lib/libGLcore.so.1 /usr/lib/libGL.so.1
They do *not* contain glUniform2i, but they *do* contain:
% objdump -S /usr/lib/libGL.so.1 | grep glUniform2i 0003d300 <glUniform2ivARB>: 3d31c: 74 20 je 3d33e <glUniform2ivARB+0x3e> 3d345: eb d7 jmp 3d31e <glUniform2ivARB+0x1e> 0003d350 <glUniform2iARB>: 3d36c: 74 20 je 3d38e <glUniform2iARB+0x3e> 3d395: eb d7 jmp 3d36e <glUniform2iARB+0x1e>
So what is the difference between glUniform2iARB and glUniform2i ?
I confirm I have and am compiling with ARB, whatever that is:
misc using ARB-extensions : yes
I did some more digging and saw this:
% file /usr/lib/libGL.so /usr/lib/libGL.so: symbolic link to `/usr/lib/libGL.so.1.0.8776' % file /usr/lib/libGL.so.1 /usr/lib/libGL.so.1: symbolic link to `libGL.so.1.2' % file /usr/lib/libGL.so.1.2 /usr/lib/libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
so libGL.so points to nvidia, but libGL.so.1 points to libGL.so.1.2 (from libgl1-mesa-glx) though dpkg -L tells me both should be diverted:
/usr/lib/libGL.so.1.2 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa /usr/lib/libGL.so.1 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa
BUT the latter (/usr/lib/nvidia/libGL.so.1.xlibmesa) seems to be broken:
% file /usr/lib/nvidia/libGL.so.1.xlibmesa /usr/lib/nvidia/libGL.so.1.xlibmesa: broken symbolic link to `libGL.so.1.2'
I already did --reinstall for libgl1-mesa-glx and nvidia-glx (in that order).
Johannes, does your machine also have that broken link and the same diversions?
Anyhow I've emailed the maintainers to see whats going on.
Is there a way I can force gem to compile against libGL.so and not libGL.so.1?
adding a manual link from libGL.so.1 to libGL.so makes Gem loose openGL entirely:
configure: error: GL not found! you need openGL!!!
ARG! Lemme know if you have any ideas...
B. Bogart
IOhannes m zmoelnig wrote:
hi
B. Bogart wrote:
Hey all,
I've now got time to revisit this issue.
#1. I've changed to the (binary blob from nvidia) that is included in the non-free repos because I'm tired of the stupid manual installation that needs to be done every time I update a machine. I must have run that *$#%*#$ installer 100 times and wasted hours of my life. So I switched to the one in the repo that will just work with debian out of the box. Only issue is its a slightly older version (87xx) rather than (97xx) but I was using gem user the 87xx series for ages without issues.
i am using the 8776 from the debian repository too (though i have a mixed stable/unstable system, but the packages installed are really 1.0.8776-4). no problems here.
so to clarify I *AM* using the nvidia binary driver, just the ones made debian friendly in their repos:
are you sure?
I confirmed that the GL headers I'm compiling against are provided by nvidia, not mesa:
glext.h:
#ifndef __glext_h_ #define __glext_h_
#ifdef __cplusplus
and glext.h does include glUniform2i:
GLAPI void APIENTRY glUniform2i (GLint, GLint, GLint);
which is basically your problem: if the headers define glUniform2i but the library does not, then you get that error.
I'm sure I'm compiling against those headers, because they are located in /usr/include/GL and the mesa headers have been renamed.
I can see that glext.h provides the declaration for glUniform2i, but what library is supposed to contain that symbol? nm says all the nvidia provided libs "contain no symbols"
i am not so firm with advanced things like "nm", but when i do "grep glUniform2i /usr/lib/libGL.so" i get "Binary file /usr/lib/libGL.so matches"
too add insult to injury I have GEM working on an almost identical machine at school with the same version of the nvidia driver from the debian repo. If I try and load the binary built on that machine here I get glUniform4iARB is unresolved. (which is defined in the same glext.h header (the same one on both machines also)
So it seams the binaries are not inline with the headers, so I have to figure out what is different about the two machines. (in terms of GL binary libs) after another hour of digging I can't tell what is the difference between the two machines, my machine has /usr/lib/libGL.a (which is supposedly provided by a debian package that I don't have installed) but renaming it made no difference.
you should NOT have a libGL.a; the thing about using openGL hardware- and software- rendering on demand is about using dynamic libraries.
I've attached my ./configure from both machines, which are pretty well identical. And here are the GL packages installed on both:
i haven't looked through these (yet).
i do believe that you are linking against the wrong openGL library.
run "ldd Gem.pd_linux" if you see that it is linking against /usr/local/lib/libGL.so then you should remove these...
hope this helps
mfgas IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig