[RFC] Xorg symbols that should not be public

[Aaron Plattner]

On Tue, Dec 09, 2008 at 02:46:15AM -0200, Paulo C?sar Pereira de Andrade wrote:
>   Hi Aaron,
> 
>   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.

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

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.

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

>   I remember last year/start of this year, when I check, the nvidia
> driver required miInitializeCompositeWrapper (don't remember if any
> other symbols). Currently that function is not in the sdk, and the
> apparently only user, libxaa has it as a hidden symbol, what probably
> is wrong.

The NVIDIA driver has an option to enable the composite wrapper, but it's
disabled by default.  If enabled, the driver will attempt to
xf86LoadSubModule libxaa to find miInitializeCompositeWrapper but will
just print a warning and continue if it can't find it.  Most of the no-CW
kinks have been worked out of our acceleration code now, so I won't shed
any tears if miInitializeCompositeWrapper goes away.

    (II) Loading sub module "xaa"
    (II) LoadModule: "xaa"
    (II) Loading /X/lib/xorg/modules//libxaa.so
    (II) Module xaa: vendor="X.Org Foundation"
            compiled for 1.6.99.1, module version = 1.2.1
            ABI class: X.Org Video Driver, version 5.0
    (WW) NVIDIA(0): UseCompositeWrapper was requested but
    (WW) NVIDIA(0):     miInitializeCompositeWrapper was not found.

>   libwfb may also need some update, wfbrename.h maybe should not be
> installed, but I don't remember if the nvidia driver used it.

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).

>   xf86Rename.h probably should not be in the sdk, but bundled with
> the drivers that provide fallbacks for older servers.

You're right, this should get pulled into the driver dist tarballs like the
rest of the files in that directory.

> > Of these, we need the following:
> >
> > LoaderGetABIVersion
> > LoaderShouldIgnoreABI
> > miCreateAlphaPicture
> > noRenderExtension
> > PictureMatchVisual
> > xf86AddGeneralHandler
> > xf86DeregisterStateChangeNotificationCallback
> > xf86DisableGeneralHandler
> > xf86EnableGeneralHandler
> > xf86RemoveGeneralHandler
> > XineramaVisualsEqualPtr
> 
>   I think all of these should always be available. And if one
> compiles with --disable-xinerama, the xinerama function should
> not be called.

I'm not sure what will happen if you try to use the driver with a server
compiled with --disable-xinerama.  In theory, it should work, but we don't
support it.

-- Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syms.gz
Type: application/octet-stream
Size: 29059 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081209/e11d757d/attachment.obj>