Dans l’article <mailman.1027558445.21147.sdl at libsdl.org>, “Bart”
a tapot? avec ses petits doigts:
Ldd output does not list libGL (wish I had thought to look at that) for
the apps which fail to work.
Speaking of ldd, when I build a program using OpenGL, ldd outputs
libGL.so and libGLcore.so as linked to the program. I suppose that
running a program linked this way will not work with Mesa or other OpenGL
implementation.
So, must I build my program against Mesa include and libs, and I will be
sure it runs with NVidia OpenGL libs, or is there another way ?
I am also thinking about the way it is done in Windows, where the OpenGL
library is dynamically loaded. It may be nice to do it also in
Linux, because esd and arts support can be built this way.–
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux
Dans l’article <mailman.1027558445.21147.sdl at libsdl.org>, “Bart”
a tapot? avec ses petits doigts:
Ldd output does not list libGL (wish I had thought to look at that)
for the apps which fail to work.
Speaking of ldd, when I build a program using OpenGL, ldd outputs
libGL.so and libGLcore.so as linked to the program. I suppose that
running a program linked this way will not work with Mesa or other
OpenGL implementation.
So, must I build my program against Mesa include and libs, and I will
be sure it runs with NVidia OpenGL libs, or is there another way ?
I am also thinking about the way it is done in Windows, where the
OpenGL library is dynamically loaded. It may be nice to do it also in
Linux, because esd and arts support can be built this way.
On my system, libGLcore.so is actually linked to libGL.so, so I assume if
you use the Mesa libGL.so, then the requirement for libGLcore.so will
disappear. This is with the NVidia drivers.
I’ve run programs that were linked to libGL.so, both under Mesa and
NVidias GL library. No relinking was required.
SteveOn July 25, 2002 12:42 pm, Patrice Mandin wrote:
Ldd output does not list libGL (wish I had thought to look at that) for
the apps which fail to work.
Speaking of ldd, when I build a program using OpenGL, ldd outputs
libGL.so and libGLcore.so as linked to the program. I suppose that
running a program linked this way will not work with Mesa or other OpenGL
implementation.
Correct. NVIDIA has fixed this in newer driver releases. Upgrading is
one option.
So, must I build my program against Mesa include and libs, and I will be
sure it runs with NVidia OpenGL libs, or is there another way ?
That is another option.
A third is to dig up my DynGL 3 stuff and bind OpenGL at runtime. It was
designed to fix these kinds of problems. Of course, it comes at a cost,
namely that my programs have two dozen or so function pointers for OpenGL
functions. Yours may have more or less.
I am also thinking about the way it is done in Windows, where the OpenGL
library is dynamically loaded. It may be nice to do it also in
Linux, because esd and arts support can be built this way.
DynGL is known to work in Win32, Linux, and MacOS X (though SDL does not
let you choose your driver under MacOS X as it does elsewhere…)On Thu, Jul 25, 2002 at 05:12:16PM +0200, Patrice Mandin wrote:
–
Joseph Carter Not many fishes
JHM: I’m not putting quake in the kernel source
but we should put quake in the boot floppies to one-up
Caldera’s tetris game… ;>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020725/a601640c/attachment.pgp