Re: Darwin extern/static fix

At 2:41 PM -0700 4/13/05, Ian Romanick wrote:
>Torrey Lyons wrote:
>>At 3:42 PM -0400 4/13/05, David Dawes wrote:
>>
>>>On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote:
>>>
>>>>Bugzilla #1576 and the fix committed for it is only partially right.
>>>>The patch applewmExt.h is right, but patching the imported Mesa code
>>>>in extras/Mesa/include/GL/internal/dri_interface.h is the wrong thing
>>>>to do and likely has unintended side effects on other platforms. The
>>>>correct fix is just to rename __driConfigOptions in
>>>>lib/GL/apple/dri_glx.c. Thanks for pointing out the issue.
>>>
>>>
>>>I didn't find anything that requires the external declaration of
>>>__driConfigOptions, which is why I applied the patch as submitted.
>>>Perhaps something should in the BUILT_IN_DRI_DRIVER case.  There
>>>are also likely other issues with the BUILT_IN_DRI_DRIVER case.
>>
>>Yes, I don't know of a specific issue, but it seems like bad 
>>practice to change an imported header file when we don't need to. 
>>The names I came up with in apple/dri_glx.c are completely 
>>arbitrary. Now that in gcc 4.0 we can't rely on static to avoid 
>>namespace collisions, those static variables should be named 
>>something more unique. In the X.Org tree I'm going to change the 
>>name of the static variables in apple/dri_glx.c. Of course there's 
>>nothing wrong with doing both this and the submitted patch.
>
>__driConfigOptions is supposed to be exported by the DRI driver. 
>The idea is that a configuration utility would open libGL and use 
>glXGetDriverConfig to get the configuration options supported by the 
>driver.  If the libGL doesn't support loading DRI drivers, as I 
>suspect is the case with the Darwin libGL, there is no reason for 
>glXGetDriverConfig to ever return *anything* other than NULL.

Interesting. Currently glXGetScreenDriver() returns "apple" and 
glXGetDriverConfig() returns an empty string, but I can see that NULL 
is more appropriate. The idea was to make porting application code 
easier by making libGL look like it can load a single "apple" driver, 
which might some day support some configuration options. Of course, 
it will probably never make sense on Mac OS X to have a real loadable 
driver

--Torrey