[RFC] Xorg symbols that should not be public

[Paulo César Pereira de Andrade]

Aaron Plattner wrote:

>>   Can you test with a install of the current X Server git master, and
>> check what symbols are missing if any? Just use the script attached.
>
> Nifty script!  I took the liberty of making it print out the paths so I
> could make sure it was picking up the right binaries.

  Thanks. You could also use the -f option, to print full pathnames :-)

> At first, the build didn't work because I configure my build directory
> with
>
>    $ /home/aaron/X/modular/xserver/configure --prefix=/X ...
>
> and all of my include paths start with "/home/aaron/X/modular/xserver",
> resulting in an empty xorg_symbols array.  Then, instead of failing to
> build, it produced an X server that did this:
>
>     dlopen: /X/lib/xorg/modules/extensions//libextmod.so: undefined
> symbol: XvScreenInitProc
>     (EE) Failed to load /X/lib/xorg/modules/extensions//libextmod.so
>     (EE) Failed to load module "extmod" (loader failed, 7)
>     (EE) Failed to load module "dri" (module does not exist, 0)
>     X: symbol lookup error: /X/lib/xorg/modules//libint10.so: undefined
> symbol: xf86ReadBIOS

  That is strange. I think this could happen only if for some reason
the cpp output was listing full pathnames, as the script logic is
very simple, it only processes output generated from headers in a
relative pathname.
  The script is used just to prevent this. If those symbols are not
referenced, the linker may drop them, as there is no code path inside
the X Server that access them.

> It would be nice if sdksyms.sh could cause the build to fail if it finds
> no
> symbols.  Also, the rule to build sdksyms.c needs a dependency on
> sdksyms.sh and all of the headers that it includes.  Otherwise, someone
> will change the SDK and then wonder why his new symbol doesn't show up
> because xorg_symbols is stale.

  A complete build should always work correctly. But it probably should
be extended to check after the X Server is linked, that those symbols
are found by dlsym.

> Once I got the build to generate sdksyms.c correctly, the resulting server
> worked fine.

> The NVIDIA driver doesn't use wfbrename.h itself, but it relies on
> libwfb.so not defining any [^w]fb symbols that will clash with ones from
> libfb.so.  From a quick skim of your nifty script's output, it looks like
> all of libwfb.so's exported symbols are properly prefixed with "wfb", so I
> think it's okay.  There are probably some symbols in wfbrename.h that have
> disappeared from the source, though, and can be removed.  (Note that it
> needs to rename everything exported when -fvisibility=hidden is disabled,
> too).

  Another test I forgot to ask, please also check that symbols accessed
using dlsym or LoaderSymbol are also exported. The script cannot find
those. But just a grep for dlsym or LoaderSymbol in the source should
tell what symbols may still fail.

Paulo