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