[PATCH] Xext: un-export all XGE functions.

Paulo César Pereira de Andrade pcpa at mandriva.com.br
Mon Dec 8 16:44:52 PST 2008

Peter Hutterer wrote:
> On Mon, Dec 08, 2008 at 07:09:13PM -0200, Paulo César Pereira de Andrade
> wrote:
>> > These functions are only to be used by X server extensions, so let's
>> not
>> > expose them to the world.
>>   This will not work as expected if the X Server is compiled with
>> hidden symbols.
>>   For the moment at least, it must be specified as both
>> extern _X_EXPORT
>> (what may be counter intuitive I agree).

  If the X Server is compiled with hidden symbols, and those symbols
are accessed by non builtin modules, they must be exported.

> Can you please summarize what the purpose of _X_EXPORT, _X_HIDDEN and
> _X_INTERNAL is now, and how the are supposed to be used?

  I think I did not express myself correctly. The usage has not
changed. But to make things more "manageable" I am trying to keep
the _X_EXPORT set on the header files. This mainly because there
are several symbols that are expanded from macros, and are not
easy to find or figure out what name they will have...
  _X_INTERNAL must be used with care, as described in the gcc info,
symbols with this attribute cannot be accessed indirectly (using
pointers) by other shared objects.
  _X_EXPORT is still used in sources for symbols accessed via
LoaderSymbol, like the "nameModuleData" structures, and a few other
cases where the function for sure should not be declared in the sdk.

  There are two kinds of symbols that must be made available by the
X Server. That are the symbols that must be made available to video
and input modules, and symbols that should be accessed only by
modules built in the X Server tree. The procedure should be the
same in the header file, just that the header would not be installed
in the sdk.

  I will try to do "as small as possible" reorganization on the sdk
headers, and add private and not installed headers. Drivers should not
have access to functions to manage clients, call the *Init functions,
and the like. But it may cause some regressions... (before pushing I
would ensure everything builds and "works for me", and test with a few
different setups).

> I only skimmed your patches and that area was always a bit unclear to me
> anyway.
> Cheers,
>   Peter


More information about the xorg mailing list