Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
There are still other places where the drivers use glXGetProcAddress. That one isn't going to go away. If I had it to do over again, I probably would have picked a different name for the GetProcAddress function used by the drivers. Probably __driGetProcAddress or something similar. At this point, I think it's a small enough issue that it's not worth the effort to change.
This means I have to build a glXGetProcAddress for linux-solo someplace like in common since in the standalone case there is nothing but the drivers. Isn't glXGetProcAddress being used for two purposes, the external one and an internal one for the drivers? If so should we make an internal one, __driGetProcAddress, and then have DRI chain the external glXGetProcAddress into __driGetProcAddress?
*Something* does a dlopen on the driver. Whatever that something is has to provide glXGetProcAddress and a couple other things to the driver. I could be convinced that drivers should call a function called __driGetProcAddress instead of glXGetProcAddress, but that function will still live the same place as the dlopen call. I guess I don't understand what you mean by "there is nothing but the drivers." There has to be something. The driver don't just load themselves. :)
Will you be available for the #dri-devel chat? We might be able to cover this faster there than via the mailing list.
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
