Re: [Nel] Issue to run snowballs2

[Lionel Berenguier]

Thank you Vincent for this great clarification. In your own experience, is
glXGetProcAddressARB widely supported ???

If yes, what I have to do is undef GL_EXT_PROTOTYPES, and use same scheme as
windows, isn't it ??


Lionel.

----- Original Message -----
From: "Vincent Caron" <address@hidden>
To: <address@hidden>
Sent: Thursday, January 10, 2002 12:04 AM
Subject: Re: [Nel] Issue to run snowballs2


> 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.
>
>
> _______________________________________________
> Nel mailing list
> address@hidden
> http://www.nevrax.org/mailman/listinfo.cgi/nel
>