Ian Romanick wrote:
>
> On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
>
> > Well, you're doing something you're not supposed to do & as a result
> > glXGetProcAddress isn't working right.
> >
> > Do you really need to call your symbol glBegin? How about xyzBegin or
> > similar?
>
> I have managed to solve this problem (see below), but first I'll give some
> background. I had a rather large chunk of OpenGL code from a non-Linux
> system that made some assumptions about what extensions would be available
> in libGL.so. It checked to make sure that the extensions were enabled in
> the driver before calling them, but it still assumed that the linker would
> be able to resolve them at load time. Since a number of these extensions
> don't exist in Mesa, the program would compile just fine, but it would not
> link.
>
> I *really* did not want to have to make changes to the source code. It is
> about 100,000 LOC, and changing the source with a bunch of ifdefs sounded
> like way too much work. My initial attempt at working around this was to
> write a script that would process glext.h and use the PFNGL* typedefs to
> create a bunch of pointers-to-functions. It also generated a table of
> structures that I would use with glXGetProcAddress to resolve the pointers.
>
> struct gl_extension
> {
> /* Name of the function that is needed.
> */
> const char * name;
>
> /* Pointer to the pointer-to-function.
> */
> void ** function;
> };
>
> A short stub routine would get called once at start up to fill in all of the
> function pointers using glXGetProcAddress. Since all of the C files
> included a header file that declared all of the extension functions as
> pointer-to-function, the compiler would generate code to call it the right
> way. If everything worked correctly, I would need to make no changes to the
> 100,000 lines of application code.
>
> Everything did work correctly UNTIL it came time to resolve a function that
> was exported by libGL.so. I believe the function that actually started the
> whole mess was glTexImage3DEXT, but it could have just as easilly been any
> of a number of functions. As near as I can tell, when ld.so loaded
> libGL.so, it saw that glTexImage3DEXT was in address space already, so it
> didn't bother to load it from the library. All references to
> glTexImage3DEXT in the library were directed to the symbol in the
> application. The end result being that glXGetProcAddress( "glTexImage3DEXT" )
> returned a pointer to the address where I was going to store it!
>
> I did find a very inelegant way to work around this (for those not
> completely following, this is a work around to a work around *grin*).
> Instead of having the script create a header file with the
> pointers-to-functions having their actual OpenGL names, it prepends foo_ to
> all of the names. glTexImage3DEXT becomes foo_glTexImage3DEXT. It then
> generates a define to redirect the OpenGL name to the foo_ name.
>
> #define glTexImage3DEXT foo_glTexImage3DEXT
>
> Since this happens in the C preprocessor, ld.so never has any knowledge of
> it. All it sees in the application is foo_glTexImage3DEXT, so it knows that
> it still needs to resolve glTexImage3DEXT from libGL.so.
>
> I *KNOW* that I cannot be the first person who has ever had to try and solve
> this problem. The OpenGL developer FAQ provides some hints, but really only
> gives enough information to get from an unlinkable application to an
> unrunable application.
>
> http://www.opengl.org/developers/faqs/technical/extensions.htm#0060
>
> How have other people solved this? If there are some particularly good
> sollutions out there, perhaps we could recommend that they be added to the
> OpenGL developer FAQ. That sure would have saved me some trouble!
I think by passing various flags to dlopen you can manipulate the behaviour
when resolving symbols in the loaded library (ie you'd have to dlopen
libGL.so, and have *all* GL operations go through function pointers).
Keith
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
