extension init cleanup
Paulo César Pereira de Andrade
pcpa at mandriva.com.br
Thu Feb 5 14:39:06 PST 2009
Tomas Carnecky wrote:
> On 02/05/2009 10:53 PM, Paulo CÃ©sar Pereira de Andrade wrote:
>> Tomas Carnecky wrote:
>>> I tried to clean up the header files that contain declarations
>>> for the various extension. Basically, in the end the header
>>> include/extinit.h contains the declarations of the extension
>>> init functions and declarations of the noXxxExtension booleans,
>>> sorted and put under their respective ifdef guards.
>>> It's that many patches because I tried to keep each commit
>>> as simple as possible, to make it easier to review. It should
>>> also be git-bisect friendly, meaning that after each single
>>> commit the tree builds.
>>> If you would rather see the patches, I can send them to the
>>> list as well. But I think I spammed the list enough yesterday
>>> so today it's just this cover mail.
>> I Just looked up superficially, as I curious about the
>> "Clean up declarations to make sdksyms.sh happy" commit.
> Actually, neither before nor after this commit does sdksyms.sh complain.
> That's because I put a whitespace before every extern declaration. I
> know that's cheatning, but I did this so I could work on the code
> without build failures - with the intention to fix it at the end, when I
> see the big picture (which functions are used from where etc).
>> I did not track in which commit the prototypes were
>> added to extinit.h, but if a symbol there is to be used
>> by other shared objects, you should use
>> extern _X_EXPORT type name();
>> and not just
>> extern type name();
>> There is already enough mess in the source tree, so, if
>> you added _X_EXPORT to the function definition, I suggest
>> reconsider :-), as it makes it harder to have automated
>> tools handling this stuff... And the only usages in sources,
>> so far are basically GL and fooModuleData.
>> The problem of adding it to sources is also mainly due
>> to way too much functions declared by macros; Things
>> things like xf86rename.h can easily get out of control.
> I kept the noXxxExtension declarations as-is (they were _X_EXPORT in
> includes/global.h, I just moved them to extinit.h). I didn't add any
> attribute to the functions though. Some are used only from within
> mi/miinitext.c (GE, SHAPE, bigreq, xkb, sync, xfixes and a few others).
> Other extensions are used from other modules (screensaver, dga, dri,
> glx, record, xv, ...).
> When I was chatting with Adam about extern and the various attributes,
> he said that he would like to make 'hidden' the default, and that you'd
> have to explicitly mark symbols for export. What's preventing us from
> using -fvisibility=hidden ?
Are you compiling with "--disable-visibility"? :-)
-fvisiblity=hidden is the default in git master for quite some
> I'm willing to add the proper attributes the the functions. However
> there still is one issue: I need to prevent sdksyms.sh from picking up
> certain declarations, like this one:
> extern void DPMSExtensionInit(void);
> This function is defined in dbe/dbe.c, but is not being linked into
> libxorg.a but into a shared library that is later loaded by Xorg. So the
> final link fails because the symbol is missing. I worked around that by
> adding a whitespace before the declaration. Shouldn't sdksyms.sh only
> pick up declarations with _X_EXPORT?
It parses cpp output, and _X_EXPORT may expand to nothing. But
sdksyms.sh also parses (ignores) the expected gcc and sun cc
But about symbols that are defined in modules under the xorg/xserver
tree, you could use the #ifdef XorgLoader trick I used for Xext headers,
(it is somewhat the logic used for XFree86LOADER, but I did not want
to use that symbol for safety...) as it is a mix of builtin and non
builtin declarations, as well as modules, i.e. part is builtin in the
Xorg binary, and part is in the extmod module.
More information about the xorg