Brian Paul wrote:
> Ian Romanick wrote:
>> Brian Paul wrote:
>>> Ian Romanick wrote:
>>>> Currently, the only functions that are aliased like this are both
>>>> GLX_SGI_make_current_read functions, a few GLX_SGIX_fbconfig
>>>> functions, and glXGetCurrentDisplayEXT (from GLX_EXT_import_context
>>>> and GLX 1.2). Since this last function has been supported for so
>>>> long in XFree86, it's the only one that I'm at all concerned about.
>>>> In the future, some of the pbuffers functions may get the same
>>> I guess I'd like to keep the existing "real" GLX extension functions
>>> whenever possible. Some apps/libs (like some varients of GLUT) have
>>> direct calls to some GLX functions like glXGetFBConfigAttribSGIX().
>>> If those functions don't exist in libGL people may have problems. I
>>> see some reports of this kind of problem with NVIDIA's libGL and
>>> older copies of GLUT as-is.
Like Mesa's xdemos/pbinfo. :)
>> I was afraid of that. I really don't want to have a bunch of gunk
>> floating around in either the source or the binary. Would it be okay
>> to use --defsym to have the linker do the aliasing? From the ld man
>> --defsym symbol=expression
>> Create a global symbol in the output file, containing
>> the absolute address given by expression. You may use
>> this option as many times as necessary to define mul-
>> tiple symbols in the command line. A limited form of
>> arithmetic is supported for the expression in this
>> context: you may give a hexadecimal constant or the
>> name of an existing symbol, or use "+" and "-" to add
>> or subtract hexadecimal constants or symbols. If you
>> need more elaborate expressions, consider using the
>> linker command language from a script. Note: there
>> should be no white space between symbol, the equals
>> sign (``=''), and expression.
> Is that going to work on all platforms that libGL may be compiled on?
> That approach would probably also require some Imake hacking.
I think it would work, but it turns out to be a VERY painful.
> Otherwise, I'd prefer to just keep the functions as-is. I don't see
> them as "gunk". Maybe moving them all into a new file would make things
Thanks to Eric's suggestion, I came up with a better way. I made a
macro called GLX_ALIAS that is either a no-op, a function call to the
aliased function, or a fancy prototype with '__attribute__ ((alias
("foo")))' magic. I wanted to do this but put everything in a separte
file, but the attribute-alias method didn't work right when I did that.
This works correctly with an unmodified version of pbinfo.