Enforcing server and API in a dlloader world

Adam Jackson ajax at nwnk.net
Sun Jun 26 19:55:22 PDT 2005


On Friday 27 May 2005 04:53, Egbert Eich wrote:
> I'm not interested in having to maintain a custom linker.
> However I would like to keep the information about exported symbols
> in a *single place*. This can either be done in files like xf86sym.c
> and friends or in the function definition. But not in two places
> because that would be error prone.

If you just want this list for documentation purposes I can probably coerce 
ctags or something into generating it.  But if you want this list to actually 
control what gets exported, then you're requiring a linker script.

> The files like xf86sym.c are still needed for the old module loader
> which is deprecated - but have we made the move to drop it entirely?

There is approximately one corner platform that I know of where the system 
libdl is not usable (linux on parisc).  And I would very much like to rip 
elfloader out from 7.1.

> If we have a way to generate these files on the fly it would be fine.
> I would expect that it should be possible to have input files which
> could be processed to create both xf86sym.c style output files as
> well as linker maps. With visibility tags in the function definition
> this would be a little harder.

Again I think I can convince ctags or a similar parser to get this.

> Furthermore our solution should be portable that means versatile
> enough to be used on the majority systems and compilers we support.

I don't know of anyone seriously using anything besides gcc or sun c to build 
X.  I can do visibility control on modern versions of either.  The ld for 
both understands linker scripts.

I would like not to worry about duplicating this information in 7.0, and just 
drop the *sym lists from 7.1 with the rest of elfloader.  Alternatively I 
could probably come up with a way to obviate their existance entirely 
(dlopen(NULL) to get a handle for the server itself, and then resolve things 
on the fly with dlsym; doesn't work on non-libdl platforms but those either 
don't exist or don't have a modular server anyway).

- ajax



More information about the xorg mailing list