Problem with SDL_GL_GetProcAddress (linux)

Hi there,

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336 drivers on gentoo
linux(i have not had chance to test it on any other distro’s).

I am trying to obtain an ARB_vertex_program function using it. However, i
always end up with a NULL address being returned.

However, when i try and get the same function using glut and
glXGetProcAddressARB, then it returns an address to the function fine.

In either case, when i get the list of extensions supported by my drivers,
ARB_vertex_program is indeed listed there.

I’m a bit puzzled as to why this problem is occuring. If it was a driver
issue, then surely i wouldn’t be able to get the function at all…

Does anyone have any ideas?

Here is the code i am using to test :

// test.c
// Test Getting an ARB_vertex_program function

//#define SDL_METHOD
// Compile test SDL version with :
// gcc -DSDL_METHOD sdl-config --libs test.c -o test

//#define GLUT_METHOD
// Compile test GLUT version with :
// gcc -DGLUT_METHOD -lGL -lGLU -lglut test.c -o test

#ifdef GLUT_METHOD
#include <GL/glut.h>
#include <stdio.h>
#define GET_GL_PROC(name) glXGetProcAddressARB(name)
#endif

#ifdef SDL_METHOD
#include <SDL/SDL.h>
#define GET_GL_PROC(name) SDL_GL_GetProcAddress(name)
#endif

void *extgl_GetProcAddress(char name)
{
printf(“Getting Proc Address for : %s\n”, name);
void t = (void)GET_GL_PROC((char
)name);
if (t == NULL)
{
printf(“Couldn’t get %s!\n”, name);
}
printf(“PROC: %d\n”, t);
return t;
}

int main(int argc, char *argv)
{
/
Initialize library’s */
#ifdef GLUT_METHOD
glutInit(&argc, argv);
glutInitWindowPosition(100, 100);
glutInitWindowSize(512, 400);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
int windowID = glutCreateWindow(“test getting extension”);
#endif

#ifdef SDL_METHOD
SDL_Init(SDL_INIT_VIDEO);
 if (SDL_GL_LoadLibrary("libGL.so") == -1 &&
SDL_GL_LoadLibrary("libGL.so.1") == -1)
{
	printf("Error loading GL library: %s\n", SDL_GetError());
	return 1;
}
#endif

/* Call the test function */

if (extgl_GetProcAddress("glGetProgramivARB") == NULL)
{
	printf("Could not get test ARB_vertex_program function\n");
	return 1;
}

/* Cleanup, if neccesary */

#ifdef SDL_METHOD
SDL_Quit();
#endif
return 0;

}

Thanks for any help,
-James

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336 drivers on gentoo
linux(i have not had chance to test it on any other distro’s).

Can you try it with SDL from CVS:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz

Please let me know ASAP if that works, since I’m gearing up for SDL 1.2.7

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam,

I removed the sdl from gentoo, downloaded the cvs archive, and configured it
doing the following :
./autogen.sh && ./configure && make all install

(NOTE: I did not use my gentoo CFLAGS though i don’t see how they would make a
difference in this context)

I compiled and ran my test program again, and it still doesn’t seem to be
working =/

SDL test:

Getting Proc Address for : glGetProgramivARB
Couldn’t get glGetProgramivARB!
PROC: 0
Could not get test ARB_vertex_program function

GLUT test:

Getting Proc Address for : glGetProgramivARB
PROC: 1074276056

I can get the function pointers in SDL for most other opengl functions fine,
which is odd…

e.g :

SDL test:

Getting Proc Address for : glFogCoordf
PROC: 1079346808

GLUT test:

Getting Proc Address for : glFogCoordf
PROC: 1074263672

It seems to only affect the ARB shader extensions oddly…
Is there anything i could do to get around this oddity?

Thanks,
-JamesOn Saturday 14 February 2004 12:58 am, Sam Lantinga wrote:

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336 drivers on
gentoo linux(i have not had chance to test it on any other distro’s).

Can you try it with SDL from CVS:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz

Please let me know ASAP if that works, since I’m gearing up for SDL 1.2.7

Do you have a small test case? If you do send it to me, I can test if
that same problem hapens to me too.On Saturday 14 February 2004 13:22, James Urquhart wrote:

On Saturday 14 February 2004 12:58 am, Sam Lantinga wrote:

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336
drivers on gentoo linux(i have not had chance to test it on any
other distro’s).

Can you try it with SDL from CVS:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz

Please let me know ASAP if that works, since I’m gearing up for SDL
1.2.7

Sam,

I removed the sdl from gentoo, downloaded the cvs archive, and
configured it doing the following :
./autogen.sh && ./configure && make all install

(NOTE: I did not use my gentoo CFLAGS though i don’t see how they
would make a difference in this context)

I compiled and ran my test program again, and it still doesn’t seem
to be working =/

SDL test:

Getting Proc Address for : glGetProgramivARB
Couldn’t get glGetProgramivARB!
PROC: 0
Could not get test ARB_vertex_program function

GLUT test:

Getting Proc Address for : glGetProgramivARB
PROC: 1074276056

I can get the function pointers in SDL for most other opengl
functions fine, which is odd…

e.g :

SDL test:

Getting Proc Address for : glFogCoordf
PROC: 1079346808

GLUT test:

Getting Proc Address for : glFogCoordf
PROC: 1074263672

It seems to only affect the ARB shader extensions oddly…
Is there anything i could do to get around this oddity?

Thanks,
-James

Can you try it with SDL from CVS:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz

Please let me know ASAP if that works, since I’m gearing up for SDL
1.2.7

Sam,

I compiled and ran my test program again, and it still doesn’t seem
to be working =/

Do you have a small test case? If you do send it to me, I can test if
that same problem hapens to me too.

Sami,

I have just sent you the test case source.
I altered it from my initial test (see the first post) to include a much wider
selection of regular gl functions aswell as the arb shader extensions.

It seems to boil down to the simple problem that all the ARB shader extension
functions are being found in GLUT, aswell as the appropriate extensions in
extension list.
However, in SDL, the extensions are found, but the functions appear to have
gone walkies and do not appear at all (which i find very unusual).

Is there anything else i could do, perhaps to determine if there is
something odd about my system setup causing this?

-JamesOn Saturday 14 February 2004 2:46 pm, Sami N??t?nen wrote:

On Saturday 14 February 2004 13:22, James Urquhart wrote:

On Saturday 14 February 2004 12:58 am, Sam Lantinga wrote:

SDL test:

Getting Proc Address for : glGetProgramivARB
Couldn’t get glGetProgramivARB!
PROC: 0
Could not get test ARB_vertex_program function

GLUT test:

Getting Proc Address for : glGetProgramivARB
PROC: 1074276056
Weird.

I can get the function pointers in SDL for most other opengl functions
fine, which is odd…

e.g :

SDL test:

Getting Proc Address for : glFogCoordf
PROC: 1079346808

GLUT test:

Getting Proc Address for : glFogCoordf
PROC: 1074263672
Are they supposed to be different addresses? Or does that not matter when
you’re dynamically loading?On Saturday 14 February 2004 05:22, James Urquhart wrote:

Sami,

I have just sent you the test case source.

Can you send it to me as well?

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

James Urquhart wrote:>On Saturday 14 February 2004 12:58 am, Sam Lantinga wrote:

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336 drivers on
gentoo linux(i have not had chance to test it on any other distro’s).

Can you try it with SDL from CVS:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz

Please let me know ASAP if that works, since I’m gearing up for SDL 1.2.7

Sam,

I removed the sdl from gentoo, downloaded the cvs archive, and configured it
doing the following :
./autogen.sh && ./configure && make all install

(NOTE: I did not use my gentoo CFLAGS though i don’t see how they would make a
difference in this context)

I compiled and ran my test program again, and it still doesn’t seem to be
working =/

SDL test:

Getting Proc Address for : glGetProgramivARB
Couldn’t get glGetProgramivARB!
PROC: 0
Could not get test ARB_vertex_program function

GLUT test:

Getting Proc Address for : glGetProgramivARB
PROC: 1074276056

I have nvidia drivers 44.96 and I can get the function pointer for
glGetProgramivARB.

On interesting thing I found is Mesa doesn’t have that function yet. So
are you sure your program is not linked with some version of Mesa that
lies somewhere on your drive ? (What I suspect is that your
/usr/lib/libGL is Mesa, while your /usr/X11R6/lib is nvidia, so by
default it uses Mesa, and when you link with glut it adds
-L/usr/X11R6/lib so it uses nvidia).

(one way to tell if you are running mesa or nvidia drivers is to look at
your program size in top, because nvidia drivers attach agp memory to
your process, and it ends up being quite big (this adds 128MB for me)).

Stephane

James Urquhart wrote:

I’ve encountered a rather frustrating problem with the function
"SDL_GL_GetProcaddress" in SDL 1.2.6, with the NVIDIA 5336 drivers on
gentoo linux(i have not had chance to test it on any other distro’s).

I have nvidia drivers 44.96 and I can get the function pointer for
glGetProgramivARB.

On interesting thing I found is Mesa doesn’t have that function yet. So
are you sure your program is not linked with some version of Mesa that
lies somewhere on your drive ? (What I suspect is that your
/usr/lib/libGL is Mesa, while your /usr/X11R6/lib is nvidia, so by
default it uses Mesa, and when you link with glut it adds
-L/usr/X11R6/lib so it uses nvidia).

(one way to tell if you are running mesa or nvidia drivers is to look at
your program size in top, because nvidia drivers attach agp memory to
your process, and it ends up being quite big (this adds 128MB for me)).

Stephane

Stephane,

Heres the GL stuff in my /usr/lib dir:

lrwxrwxrwx 1 root root 35 Feb 15 00:35 /usr/lib/libGL.la
-> /usr/lib/opengl/nvidia/lib/libGL.la
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so.1
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
-rw-r–r-- 1 root root 665514 Feb 14 22:32 /usr/lib/libGLU.a
-rw-r–r-- 1 root root 769 Feb 14 22:32 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so ->
libGLU.so.1.3
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so.1
-> libGLU.so.1.3
-rwxr-xr-x 1 root root 565405 Feb 14 22:32 /usr/lib/libGLU.so.1.3
lrwxrwxrwx 1 root root 48 Feb 15 00:35 /usr/lib/libGLcore.so
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336
lrwxrwxrwx 1 root root 48 Feb 15
00:35 /usr/lib/libGLcore.so.1
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336

And in my /usr/X11R6/lib :

lrwxrwxrwx 1 root root 12 Feb 14 22:32 libGL.so.1 ->
libMesaGL.so
-rw-r–r-- 1 root root 27614 Feb 14 22:32 libGLw.a
lrwxrwxrwx 1 root root 44 Feb 15 00:35 libMesaGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336

So it seems that in all cases, its pointing to drivers
in /usr/lib/opengl/nvidia/lib/

I also checked the includes. They are all pointing
to /usr/lib/opengl/nvidia/include/* - except for glext.h… Though i tried
changing it and recompiling SDL, but it didn’t seem to have any effect.

The top stats for both glut and sdl programs seem to be similar.

-JamesOn Monday 16 February 2004 15:54, Stephane Marchesin wrote:

On Saturday 14 February 2004 12:58 am, Sam Lantinga wrote:

James Urquhart wrote:

Stephane,

Heres the GL stuff in my /usr/lib dir:

lrwxrwxrwx 1 root root 35 Feb 15 00:35 /usr/lib/libGL.la
-> /usr/lib/opengl/nvidia/lib/libGL.la
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so.1
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
-rw-r–r-- 1 root root 665514 Feb 14 22:32 /usr/lib/libGLU.a
-rw-r–r-- 1 root root 769 Feb 14 22:32 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so ->
libGLU.so.1.3
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so.1
-> libGLU.so.1.3
-rwxr-xr-x 1 root root 565405 Feb 14 22:32 /usr/lib/libGLU.so.1.3
lrwxrwxrwx 1 root root 48 Feb 15 00:35 /usr/lib/libGLcore.so
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336
lrwxrwxrwx 1 root root 48 Feb 15
00:35 /usr/lib/libGLcore.so.1
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336

And in my /usr/X11R6/lib :

lrwxrwxrwx 1 root root 12 Feb 14 22:32 libGL.so.1 ->
libMesaGL.so
-rw-r–r-- 1 root root 27614 Feb 14 22:32 libGLw.a
lrwxrwxrwx 1 root root 44 Feb 15 00:35 libMesaGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336

Your libs seem fine.

I tried with nvidia drivers 5336 and I can get the function pointer for
glGetProgramivARB fine so that’s not an issue with this particular
nvidia driver version.

You should also check your programs are linked to the right opengl libs,
to check that you can do a “ldd myprogram” and look at which libGL libs
your two programs use. If the libGL are different, we’ve found the
issue. If not, you will have to try the following :

  • link using a different order for your libs, i.e. change things like
    -lX -lY -lZ to -lZ -lY -lX
  • try using LD_PRELOAD to preload some libs before others :
    export LD_PRELOAD=/usr/lib/libGL.so

Stephane

James Urquhart wrote:

Stephane,

Heres the GL stuff in my /usr/lib dir:

lrwxrwxrwx 1 root root 35 Feb 15 00:35 /usr/lib/libGL.la
-> /usr/lib/opengl/nvidia/lib/libGL.la
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
lrwxrwxrwx 1 root root 44 Feb 15 00:35 /usr/lib/libGL.so.1
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336
-rw-r–r-- 1 root root 665514 Feb 14 22:32 /usr/lib/libGLU.a
-rw-r–r-- 1 root root 769 Feb 14 22:32 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so ->
libGLU.so.1.3
lrwxrwxrwx 1 root root 13 Feb 14 22:32 /usr/lib/libGLU.so.1
-> libGLU.so.1.3
-rwxr-xr-x 1 root root 565405 Feb 14 22:32 /usr/lib/libGLU.so.1.3
lrwxrwxrwx 1 root root 48 Feb 15 00:35 /usr/lib/libGLcore.so
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336
lrwxrwxrwx 1 root root 48 Feb 15
00:35 /usr/lib/libGLcore.so.1
-> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.5336

And in my /usr/X11R6/lib :

lrwxrwxrwx 1 root root 12 Feb 14 22:32 libGL.so.1 ->
libMesaGL.so
-rw-r–r-- 1 root root 27614 Feb 14 22:32 libGLw.a
lrwxrwxrwx 1 root root 44 Feb 15 00:35 libMesaGL.so
-> /usr/lib/opengl/nvidia/lib/libGL.so.1.0.5336

So it seems that in all cases, its pointing to drivers
in /usr/lib/opengl/nvidia/lib/

I also checked the includes. They are all pointing
to /usr/lib/opengl/nvidia/include/* - except for glext.h… Though i tried
changing it and recompiling SDL, but it didn’t seem to have any effect.

The top stats for both glut and sdl programs seem to be similar.

Also, could you send me your source if you don’t mind (or even better -
put it online so that everyone can look at it) ?

Thanks,
Stephane

Hi
I just looked through the SDL_opengl.h and was rather surprised not to
find any vertex/fragment program extensions there - is that by purpose?
I guess it would be quite nice if they were included because you have to
include another glext header at the moment if you want to use them …

BR
Arne

Hi
I just looked through the SDL_opengl.h and was rather surprised not to
find any vertex/fragment program extensions there - is that by purpose?
I guess it would be quite nice if they were included because you have to
include another glext header at the moment if you want to use them …

An oversight. I’ve added the latest version of glext.h to CVS.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment