On Tue, Oct 14, 2003 at 09:50:07PM +0200, Jakub Jelinek wrote:
>> I'd say it would be better to reuse *-def.cpp files (didn't know something
>> like that existed).
>
>I've preprocessed all *-def.cpp files included in XFree86/xc/lib, gathered
>all symbols currently exported from XFree86 shared libraries, all undefined symbols
>in > 5800 shared libraries and binaries I found on my box which are
>satisfied by one of XFree86 shared libraries and attached are results.
>
>The first is a MUST list, symbols which are exported from XFree86 shared
>libraries now when there is no anonymous version script, are not exported
>when an anonymous versions script created from stock *-def.cpp file
>is applied and are used by some binary or shared library (including other
>shared libraries in the XFree86 collection). There is IMHO no way other
>than adding these to *-def.cpp files (any issues with this)?

There is a good chance that some of these are unintentionally omitted
from the -def.cpp files.  That's less likely to be a problem as more
platforms begin using this data.  Checking the MUST list against the
API specs is the best way to determine which are unintentional.  Hopefully
that will result in a much smaller list.  That list is interesting from
the point of view of reconciling the specs with actual usage.

It is also possible that the -def.cpp export some symbols that shouldn't
be exported, and that check against the API specs needs to be made too.

>For libGL.so, as anonymous version scripts accept wildcards, I think
>we should use gl* wildcard, as it is too error-prone to list all
>the gl* functions.

Will the wildcard method work for the platforms that currently use the
-def.cpp lists?  The GL and GLX APIs should be well-defined.

>For libGLU.so, I think we should export everything, no version script
>on Linux.
>
>Second is a MAY list. These are symbols ATM exported from the shared
>libraries, which would be hidden by linker script but which looked to me
>like they are in the standard namespace of the libraries and thus might
>be good candidates for exports.
>Can anyone please review these and tell me if there are some which
>definitely shouldn't be exported?

They need to be checked against the API specs too.

>I can supply a tarball with all the symbols ATM exported, exported via
>*-def.cpp, used etc. to interested parties if you want to do more
>investigations.
>
>I'll follow up with a patch which exports MUST + current *-def.cpp ones
>and will wait for responses about the MAY list (or candidates not even
>on MAY list).
>
>       Jakub

  -- MUST list --

>libGL.so
>       XF86DRIAuthConnection
>       XF86DRICloseConnection
>       XF86DRICloseFullScreen
>       XF86DRICreateContext
>       XF86DRICreateDrawable
>       XF86DRIDestroyContext
>       XF86DRIDestroyDrawable
>       XF86DRIGetClientDriverName
>       XF86DRIGetDeviceInfo
>       XF86DRIGetDrawableInfo
>       XF86DRIOpenConnection
>       XF86DRIOpenFullScreen
>       XF86DRIQueryDirectRenderingCapable
>       XF86DRIQueryVersion

All of those are used by the DRI driver modules.  I believe there are
plans for having those modules use another mechanism for accessing these
functions, but they'd still need to be exported for compatibility.
Another alternative might be splitting them into a separate shared
library that our libGL dlopen's.  I don't know if any applications directly
access the DRI extension.

>libXext.so
>       XShmAttach
>       XShmCreateImage
>       XShmCreatePixmap
>       XShmDetach
>       XShmGetEventBase
>       XShmGetImage
>       XShmPixmapFormat
>       XShmPutImage
>       XShmQueryExtension
>       XShmQueryVersion

Those definitely get added.

 -- MAY list --

>libX11.so
>       KeySymToUcs4
>       XkbChangeKeycodeRange
>       Xutf8DrawImageString
>       Xutf8DrawString
>       Xutf8DrawText
>       Xutf8LookupString
>       Xutf8ResetIC
>       Xutf8SetWMProperties
>       Xutf8TextEscapement
>       Xutf8TextExtents
>       Xutf8TextPerCharExtents

The Xutf8 functions are part of our extensions to Xlib, so should be exported.

Hopefully others can give you some more feedback about the areas they are
more familiar with.

David
-- 
David Dawes                                     X-Oz Technologies
www.XFree86.org/~dawes                          www.x-oz.com
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to