Hi all,
I seem to be doing something wrong. I am writing an xmms visualization plugin and found
that replacing all the nasty glx stuff with the nice sdl ones would make my code look
cleaner. I converted the code and it compiles fine, but something must be going wrong
during the linking process.
Whenever I enable the plugin and SDL_SetVideoMode gets called, i get this error
message:
Could not retrieve OpenGL functions
This does not happen with e.g. the opengl demos using sdl; what causes this - or how
can i debug this?
The applications all get linked against mesa.--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
Could not retrieve OpenGL functions
This means it’s trying to query for the glX symbols but can’t find
them.
The applications all get linked against mesa.
Are you sure? What does an ldd against your binary show?
m.On Fri, Mar 03, 2000 at 05:43:14PM +0100, phoenix at minion.de wrote:
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
In article <20000303090013.C744 at namaste.lokigames-lan.com>, Michael Vance wrote:> On Fri, Mar 03, 2000 at 05:43:14PM +0100, @Christian_Zander wrote:
Could not retrieve OpenGL functions
This means it’s trying to query for the glX symbols but can’t find
them.
The applications all get linked against mesa.
Are you sure? What does an ldd against your binary show?
Yes, it is linked:
Chronos:~/devel/projects/opengl/fx# ldd ./libfx.so
libGL.so.1 => /usr/local/lib/libGL.so.1 (0x4000b000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40191000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402b5000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x402e9000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x402ec000)
libdl.so.2 => /lib/libdl.so.2 (0x4030e000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40312000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4031a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40326000)
libm.so.6 => /lib/libm.so.6 (0x403c8000)
libglade.so.0 => /usr/lib/libglade.so.0 (0x403e5000)
libxml.so.1 => /usr/lib/libxml.so.1 (0x403fb000)
libz.so.1 => /usr/lib/libz.so.1 (0x40450000)
libSDL-1.1.so.0 => /usr/local/lib/libSDL-1.1.so.0 (0x4045f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x404ec000)
libc.so.6 => /lib/libc.so.6 (0x40500000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x405dd000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x405e4000)
How would i go about using SDL_GL_LoadLibrary and SDL_GetProcAddress?
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
phoenix at minion.de wrote:
How would i go about using SDL_GL_LoadLibrary and SDL_GetProcAddress?
for an SDL app that uses SDL_GL_LoadLibrary and SDL_GetProcAddress to
dlopen libGL have a look at openut.sourceforge.net. Be aware that the
code is under the artistic license if you want to use it. Basically you
don’t gain anything by dlopening it - you could use LD_PRELOAD.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
In article <38BFF7DF.65CBB2DD at grafzahl.de>, Daniel Vogel <666 at grafzahl.de> wrote:
@Christian_Zander wrote:
How would i go about using SDL_GL_LoadLibrary and SDL_GetProcAddress?
for an SDL app that uses SDL_GL_LoadLibrary and SDL_GetProcAddress to
dlopen libGL have a look at openut.sourceforge.net. Be aware that the
code is under the artistic license if you want to use it. Basically you
don’t gain anything by dlopening it - you could use LD_PRELOAD.
Ok, I didn’t link libfx.so agains libGL.so this time around and used LD_PRELOAD.
It actually works that way ?! What could cause libsdl to fail loading the glx symbols when
libGL.so is linked in, but not if it was preloaded by ld?--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
phoenix at minion.de wrote:
Ok, I didn’t link libfx.so agains libGL.so this time around and used LD_PRELOAD.
It actually works that way ?! What could cause libsdl to fail loading the glx symbols when
libGL.so is linked in, but not if it was preloaded by ld?
I don’t know what libfx.so is, but if it dlopens libGL.so without
RTLD_GLOBAL you run into problems as SDL then can’t dlopen it.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
In article <38C0152C.647A9460 at grafzahl.de>, Daniel Vogel <666 at grafzahl.de> wrote:
I don’t know what libfx.so is, but if it dlopens libGL.so without
RTLD_GLOBAL you run into problems as SDL then can’t dlopen it.
libfx.so is a simple xmms plugin. I used to use glx/xlib to create opengl contexts, but
found sdl to look cleaner. Until now, linking libGL.so by simply adding -lGL to gcc’s
command line (linking stage) worked fine, but sdl doesn’t seem to accept it.
What can I do to make sure that it mesa gets linked in a way that allows using it with
SDL?--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
How would i go about using SDL_GL_LoadLibrary and SDL_GetProcAddress?
for an SDL app that uses SDL_GL_LoadLibrary and SDL_GetProcAddress to
dlopen libGL have a look at openut.sourceforge.net. Be aware that the
You gain lots, specifically the ability to have your user swap in and
out GL libraries at runtime by specifying a different library. The
drawback is that you have to query the library for pointers explicitly
in your app…
The code flow is like this:
- Get library name from somewhere like argv, stuff in a variable
’opengl_library’, which would look something like “libGL.so.1” or
"libMesaVoodooGL.so.3.2"
- SDL_GL_LoadLibrary( opengl_library );
- Query your vast array of pointers like so:
OpenGLDevice::glIsTexture = (GLboolean (*)( GLuint )
SDL_GL_GetProcAddress( “glIsTexture” );
- Use your pointers instead of GL entry points:
if( OpenGLDevice::glIsTexture( id ) ) {
OpenGLDevice::glDeleteTextures( 1, &id );
}
m.On Fri, Mar 03, 2000 at 06:35:27PM +0100, Daniel Vogel wrote:
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
Ok, I didn’t link libfx.so agains libGL.so this time around and used
[…]
It actually works that way ?! What could cause libsdl to fail
loading the glx symbols when libGL.so is linked in, but not if it
was preloaded by ld?
Hm, the 3.3. Mesa built with configure doesn’t maintain proper link
information, but that shouldn’t cause the problem you’re seeing…
m.On Fri, Mar 03, 2000 at 07:22:40PM +0100, phoenix at minion.de wrote:
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
Michael Vance wrote:
You gain lots, specifically the ability to have your user swap in and
out GL libraries at runtime by specifying a different library. The
How many people do this in real life? I’d say noone. But I agree that
dlopen is a cool tool (especially for plugins).
drawback is that you have to query the library for pointers explicitly
in your app…
I guess this would be too ‘high level’ for SDL, but how about adding an
easy way to dlopen libGL by providing a framework of some sort (header
file with macros - if someone remembers I did post a perl script that
generates one for dlopening SDL some time ago)?–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
How many people do this in real life? I’d say noone. But I agree that
dlopen is a cool tool (especially for plugins).
Quake 2 and 3? Heretic II? Heavy Gear II? 
m.On Mon, Mar 06, 2000 at 07:08:33PM +0100, Daniel Vogel wrote:
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
Michael Vance wrote:
How many people do this in real life? I’d say noone. But I agree that
dlopen is a cool tool (especially for plugins).
Quake 2 and 3? Heretic II? Heavy Gear II?
I know that these programs have the possibility to do it But my point
rather was which user does it - cool for debugging, but you rarely
switch the lib in a real game. Or how often did you catch yourself
switching in a multiplayer match ;)> On Mon, Mar 06, 2000 at 07:08:33PM +0100, Daniel Vogel wrote:
–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Michael Vance wrote:
How many people do this in real life? I’d say noone. But I agree that
dlopen is a cool tool (especially for plugins).
Quake 2 and 3? Heretic II? Heavy Gear II?
I know that these programs have the possibility to do it But my point
rather was which user does it - cool for debugging, but you rarely
switch the lib in a real game. Or how often did you catch yourself
switching in a multiplayer match 
IMHO it’s mainly a programmer tool. It does have another useful feature, though
– you can use it to select the profiler version of Mesa and turn that on when
you want to profile. There’s a little profile flag in Jabberwock (my 3D client)
where if you set it in the configuration file will load the profiler version of
the libraries which are stuck in my hard drive (if they’re there).
Now isn’t that cool?
–
Daniel Vogel My opinions may have changed,
Nicholas>> On Mon, Mar 06, 2000 at 07:08:33PM +0100, Daniel Vogel wrote:
I know that these programs have the possibility to do it But my point
rather was which user does it - cool for debugging, but you rarely
switch the lib in a real game. Or how often did you catch yourself
switching in a multiplayer match
A user needs to be able to do this for HG2 if they, for instance, want
to use CVAs, which are broken in Mesa 3.2 for HG2 (and work in Mesa
3.3). But I don’t want people to have to use the unstable 3.3 release
if they don’t want to, etc. All the games I listed support this
functionality not for debugging but for easing the user’s experience
in the frightening world of Linux’s current OpenGL support… although
of course it does make debugging much easier.
In Quake*, you can do a vid_restart which will totally reload the
OpenGL subsystem, allowing you to switch from, say, a G400 in window
to a Voodoo 2 in fullscren mode. Just pull down the Q3 console and
type ‘\vid_restart’ some time to force an “identity” reload.
m.On Tue, Mar 07, 2000 at 12:33:59PM +0100, Daniel Vogel wrote:
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
vining at pacificcoast.net schrieb am 07 Mar 2000:
IMHO it’s mainly a programmer tool. It does have another useful feature, though
– you can use it to select the profiler version of Mesa and turn that on when
you want to profile. There’s a little profile flag in Jabberwock (my 3D client)
where if you set it in the configuration file will load the profiler version of
the libraries which are stuck in my hard drive (if they’re there).
How’s well is the Mesa profiling working? The docs of my Mesa (3.1)
say “Profiling: [this may no longer work in Mesa 3.1]”. Also, is there
a way to start profiling between specific places in the program? (e.g.
only in frames where fog is used etc.)? Which version of Mesa should
I use?
- Andreas–
Probably one of the smallest 3D-Games in the world: http://www.gltron.org
More than 60’000 Downloads of the latest version (0.53)
I know that these programs have the possibility to do it But my point
rather was which user does it - cool for debugging, but you rarely
switch the lib in a real game. Or how often did you catch yourself
switching in a multiplayer match
A user needs to be able to do this for HG2 if they, for instance, want
to use CVAs, which are broken in Mesa 3.2 for HG2 (and work in Mesa
3.3). But I don’t want people to have to use the unstable 3.3 release
if they don’t want to, etc. All the games I listed support this
functionality not for debugging but for easing the user’s experience
in the frightening world of Linux’s current OpenGL support… although
of course it does make debugging much easier.
Heheh… “frightening world” is right. I keep on finding things not working as
they should be.
On a side note relevant to HG2 but nothing else, it seems that CVAs work fine
under Mesa 3.1 (and I think 3.1 and 3.2 share the same CVA code) as long as you
unlock the arrays before the net call to glVertexPointer/glTexCoordPointer. You
COULD implement a hack which checked the version number … I think there is an
extension, or just check the actual physical name of the library – so that
with 3.2 and below it did this. It still seems to speed up renderers a bit (I
just tried it with Aftershock)
This really needs fixing, quite urgently too. I wonder if we can pay Keith
Whitwell.
m.
N>On Tue, Mar 07, 2000 at 12:33:59PM +0100, Daniel Vogel wrote: