Re: [Nel] Issue to run snowballs2

[Vincent Caron]

On Wed, 2002-01-09 at 11:21, Lionel Berenguier wrote:
> 
> If someone could explains me where I am wrong in
> driver_opengl_extension_def.h, it would be cool.
> 
> Also, can anybody explains me why under linux/unix we don't have to
> dynamically import functions (ie with such call like wglGetProcAdress(), or
> window's GetProcAdress()) ??? In other terms, What system underlie the
> dynamic library loader (I suppose there is system which fill a table of jump
> or something like this but I don't really knows).

OpenGL under Unix was used for a long time on a limited set of video
hardware (on SGI/Irix, HP/UX and a few), and there were little migration
of software across these different setups. Thus, the extensions were
simply compiled in libGL.so together with the standard API, and you had
only two solution : 1) choose extension usage at compile time or 2)
dynamically load different versions of your engine (if the DLL wouldn't
load, it meant a required extension was not present).

But of course it was quickly a pb. An extension has been proposed as the
counterpart of wglGetProcAddress (
http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt
). Since you have the pb of the chicken and the egg (how do you get the
glXGetProcAddressARB function address without itself ? :)), the author
asked driver implementors to _always_ compile this one in their libGL.so
(even if it always return NULL : no extension!). Conclusion: you can
reuse the code currently embraced by #ifdef NL_OS_WINDOWS/#endif for
Linux, replacing wglGetProcAddress by glXGetProcAddressARB (may I
suggest a macro ? :)).

Now you would say : ok, but the gl* extensions are defined twice ! Once
as function pointers in my code, once as functions in libGL.so ! The
fact is that dlopen'ing("/usr/lib/libGL.so") does not import libGL
symbols in your process space. You have to import them with dlsym(), or
in our precise case, with glXGetProcAddressARB(). You get the Windows
behaviour. But Linux users keep a slight advantage : they can code
nVidia specific stuff without those boring function pointer mess, they
just link against libGL.so.

--
There is something worth mentioning : glXGetProcAddressARB is
context-independent while wglGetProcAddress is ! This is spurious,
because wgl* functions are on the windowing system side, and should not
be context-dependent until one of their parameter is a context. If a
Windows host has several drivers (often the case : one software, and one
HW, maybe more with multi-head), context is critical since you can deal
with several driver interfaces. At least it is clearly mentioned in the
first line of the MSDN doc...

--
Add-on: to list symbols of a DLL, use 'nm -D <stuff>.so|less'. Symbols
with a leading 'U' are undefined (meaning their implementation reside in
another lib), those with a 'T' are implemented here (in the 'text
section' = code segment). Very useful if you want to understand the
strategy of the runtime loader.