Hi all,
I've been trying to compile and run Gem on my Fedora 5 box, i386, clean install, on-board Intel graphics. Gem fails to load complaining as follows:
$ pd/bin/pd -nogui -lib Gem/src/Gem ./Gem/src/Gem.pd_linux: ./Gem/src/Gem.pd_linux: undefined symbol: +glGetShaderInfoLog Gem/src/Gem: can't load library
Gem works fine on another machine I'm using with the proprietry nvidia driver. Is there a way to either: (1) install the "GLX shader" extension on generic hardware, or (2) compile Gem with "shading" disabled?
thanks Miller
You can run configure with the option --with-glversion=1.5 which might help. It is very odd that just one of the functions out of dozens supporting shaders is not found though.
On 4/17/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Hi all,
I've been trying to compile and run Gem on my Fedora 5 box, i386, clean install, on-board Intel graphics. Gem fails to load complaining as follows:
$ pd/bin/pd -nogui -lib Gem/src/Gem ./Gem/src/Gem.pd_linux: ./Gem/src/Gem.pd_linux: undefined symbol: +glGetShaderInfoLog Gem/src/Gem: can't load library
Gem works fine on another machine I'm using with the proprietry nvidia driver. Is there a way to either: (1) install the "GLX shader" extension on generic hardware, or (2) compile Gem with "shading" disabled?
thanks Miller
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks Chris,
I assume it's all the "shader" functions and dlopen() is only reporting the first one before giving up. I sure wish there were a way only to disable Gem objects using the "shader" extension or even better find out how to get the extension installed on generic hardware...
cheers Miller
On Tue, Apr 17, 2007 at 09:26:31PM -0500, chris clepper wrote:
You can run configure with the option --with-glversion=1.5 which might help. It is very odd that just one of the functions out of dozens supporting shaders is not found though.
On 4/17/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Hi all,
I've been trying to compile and run Gem on my Fedora 5 box, i386, clean install, on-board Intel graphics. Gem fails to load complaining as follows:
$ pd/bin/pd -nogui -lib Gem/src/Gem ./Gem/src/Gem.pd_linux: ./Gem/src/Gem.pd_linux: undefined symbol: +glGetShaderInfoLog Gem/src/Gem: can't load library
Gem works fine on another machine I'm using with the proprietry nvidia driver. Is there a way to either: (1) install the "GLX shader" extension on generic hardware, or (2) compile Gem with "shading" disabled?
thanks Miller
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
Thanks Chris,
I assume it's all the "shader" functions and dlopen() is only reporting the first one before giving up. I sure wish there were a way only to disable Gem objects using the "shader" extension or even better find out how to get the extension installed on generic hardware...
well i am dreaming of 2 things to solve this:
- use GLEW (which does dynamic (runtime) checking of openGL-extensions
and uses them if possible); chris already had a version of Gem for windows compiled against GLEW, unfortunately there were now checks done to ensure that the used driver actually understood the library calls....basically this means that Gem loads (in w32 land) with whatever openGL-lib installed, but as soon as you are actually using one of the more advanced stuff which happens to be unsupported by your drivers (e.g. shaders) this will crash. it would take some work to not only use the GLEW functions stubs but also to check whether the calls are supported; i guess this work is rather easy but dull
- split Gem into a core library (with almost no objects and
dependencies) and a whole bunch of single-object externals. so if the [glsl_vertex] object uses calls unknown to your driver, this object will refrain from loading but it won't hinder Gem from working.
mfga.sdr IOhanes
On 4/18/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
it would take some work to not only use the GLEW functions stubs but also to check whether the calls are supported; i guess this work is rather easy but dull
It would take a long time to put GLEW checks in every object that uses GL, but that is probably not needed. Starting with the most troublesome objects like the shader and texturing objects would be less work but the results would be incomplete.
The big problem I found with GLEW is that, on Windows at least, it requires a working window context in order to return the correct info. The assumption appears to be that you only use OpenGL for games and the first thing your game does is take complete control of the computer and put a fullscreen context up. You are writing a game right? Any checks I put in GemMan were worthless and so are checks in the object constructors. That limits the usefulness of GLEW although a check in startRender() can work for certain features.
On Apr 18, 2007, at 3:06 AM, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
Thanks Chris,
I assume it's all the "shader" functions and dlopen() is only
reporting the first one before giving up. I sure wish there were a way only to disable Gem objects using the "shader" extension or even better
find out how to get the extension installed on generic hardware...well i am dreaming of 2 things to solve this:
- use GLEW (which does dynamic (runtime) checking of openGL-
extensions and uses them if possible); chris already had a version of Gem for windows compiled against GLEW, unfortunately there were now checks
done to ensure that the used driver actually understood the library calls....basically this means that Gem loads (in w32 land) with
whatever openGL-lib installed, but as soon as you are actually using one of the more advanced stuff which happens to be unsupported by your drivers (e.g. shaders) this will crash. it would take some work to not only use the GLEW functions stubs but also to check whether the calls are supported; i guess this work is rather easy but dull
- split Gem into a core library (with almost no objects and
dependencies) and a whole bunch of single-object externals. so if the [glsl_vertex] object uses calls unknown to your driver, this object will refrain from loading but it won't hinder Gem from working.
Perhaps this is not surprising, but this sounds good to me :). What
would the disadvantages be? It would make Gem behave like the bulk
of libs (minus pdp, pidip, msd, or any others that are optionally
linked into one dll). That would also help with the couple of
remaining name conflicts in Gem, like scale, curve, etc.
.hc
mfga.sdr IOhanes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
- split Gem into a core library (with almost no objects and
dependencies) and a whole bunch of single-object externals. so if the [glsl_vertex] object uses calls unknown to your driver, this object will refrain from loading but it won't hinder Gem from working.
Perhaps this is not surprising, but this sounds good to me :). What
would the disadvantages be? It would make Gem behave like the bulk
of libs (minus pdp, pidip, msd, or any others that are optionally
linked into one dll). That would also help with the couple of
remaining name conflicts in Gem, like scale, curve, etc..hc
I agree with Hans-Christohpe. I finally got Gem running on my machine simply by deleting all the "manips" starting with glsl (just deleted the files and recompiled). The easiest thing would be just adding a configure switch, but it might be smarter to spin off code that has non-free dependencies into one or more separate libs.
cheers Miller
mfga.sdr IOhanes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
.hc
I agree with Hans-Christohpe. I finally got Gem running on my machine simply by deleting all the "manips" starting with glsl (just deleted the files and recompiled). The easiest thing would be just adding a configure switch, but it might be smarter to spin off code that has non-free dependencies into one or more separate libs.
well, i have had a hard time with configure switches: i once added the disable-NV and disable-ARB switches, which just delayed the problem till the advent of the glsl-shaders; i don't think a configure switch for any possible driver is doable so i ended up providing a very generic configure switch "--with-glversion" which should allow you to enforce that no calls from openGL-specs higher than the given version number are used. e.g. "--with-glversion=1.5" should disable all openGL-2.0 (and up) calls, which effectively also disables the glsl-stuff. in my experience, this works pretty well.
chris has proposed this already for you, have you tried it and did it not work?
deleting files from the canonical source is definitely not the way to go (on the long run),
mfga.sdr IOhannes
does anyone know (or rather: is there) a way to dynamically link objects together and then strip all unused dependencies?
Oh yes, I had tried "disable-ARB" hoping that would turn off glsl :)
I haven't tried "--with-glversion"... will do that next time I guess.
thanks Miller
On Thu, Apr 19, 2007 at 08:58:26AM +0200, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
.hc
I agree with Hans-Christohpe. I finally got Gem running on my machine simply by deleting all the "manips" starting with glsl (just deleted the files and recompiled). The easiest thing would be just adding a configure switch, but it might be smarter to spin off code that has non-free dependencies into one or more separate libs.
well, i have had a hard time with configure switches: i once added the disable-NV and disable-ARB switches, which just delayed the problem till the advent of the glsl-shaders; i don't think a configure switch for any possible driver is doable so i ended up providing a very generic configure switch "--with-glversion" which should allow you to enforce that no calls from openGL-specs higher than the given version number are used. e.g. "--with-glversion=1.5" should disable all openGL-2.0 (and up) calls, which effectively also disables the glsl-stuff. in my experience, this works pretty well.
chris has proposed this already for you, have you tried it and did it not work?
deleting files from the canonical source is definitely not the way to go (on the long run),
mfga.sdr IOhannes
does anyone know (or rather: is there) a way to dynamically link objects together and then strip all unused dependencies?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette