[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: Enforcing server and API in a dlloader world
From: Adam Jackson <ajax () nwnk ! net>
Date: 2005-06-27 2:55:22
Message-ID: 200506262255.22470.ajax () nwnk ! net
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic