Re: Export symbol lists on Linux (was Re: RFC Marking private symbols in XFree86 shared libraries as private)
Jakub Jelinek wrote: 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)? 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. Sorry for taking so long to reply. I was taking a few days off. :) libGL.so needs to export XF86DRI*, __glXFindDRIScreen, and a few _glapi functions on all platforms that support DRI (i.e., Linux and *BSD currently). Do a nm /usr/X11R6/lib/modules/dri/*_dri.so | grep ' U _glapi' | sort -u to see which ones. On all platforms all symbols matching gl[A-Z]* need to be exported. Other than that I don't think anything needs to be exported by libGL.so. I *believe* that the *_dri.so files only need to export __driCreateScreen. There are some other symbols that need to be exported in DRI CVS, but that code isn't in XFree86 CVS AFAIK (and won't be until after 4.4.0). Thanks for tackling this! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Export symbol lists on Linux (was Re: RFC Marking private symbols in XFree86 shared libraries as private)
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
Export symbol lists on Linux (was Re: RFC Marking private symbols in XFree86 shared libraries as private)
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)? 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. 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? 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 libGL.so XF86DRIAuthConnection XF86DRICloseConnection XF86DRICloseFullScreen XF86DRICreateContext XF86DRICreateDrawable XF86DRIDestroyContext XF86DRIDestroyDrawable XF86DRIGetClientDriverName XF86DRIGetDeviceInfo XF86DRIGetDrawableInfo XF86DRIOpenConnection XF86DRIOpenFullScreen XF86DRIQueryDirectRenderingCapable XF86DRIQueryVersion __glXFindDRIScreen __glXInitialize _gl_tls_Context _glapi_Context _glapi_add_entrypoint _glapi_check_multithread _glapi_get_context _glapi_get_dispatch_table_size _glapi_noop_enable_warnings _glapi_set_context _glapi_set_dispatch _glthread_GetID glColorSubTable glColorTable glColorTableEXT glConvolutionFilter1D glConvolutionFilter2D glFogCoorddvEXT glFogCoordfEXT glFogCoordfvEXT glMultiTexCoord1dvARB glMultiTexCoord1fARB glMultiTexCoord1fvARB glMultiTexCoord1ivARB glMultiTexCoord1svARB glMultiTexCoord2dvARB glMultiTexCoord2fARB glMultiTexCoord2fvARB glMultiTexCoord2ivARB glMultiTexCoord2svARB glMultiTexCoord3dvARB glMultiTexCoord3fARB glMultiTexCoord3fvARB glMultiTexCoord3ivARB glMultiTexCoord3svARB glMultiTexCoord4dvARB glMultiTexCoord4fARB glMultiTexCoord4fvARB glMultiTexCoord4ivARB glMultiTexCoord4svARB glSecondaryColor3bvEXT glSecondaryColor3dvEXT glSecondaryColor3fEXT glSecondaryColor3fvEXT glSecondaryColor3ivEXT glSecondaryColor3svEXT glSecondaryColor3ubEXT glSecondaryColor3ubvEXT glSecondaryColor3uivEXT glSecondaryColor3usvEXT libGLU.so export all? libICE.so _IceTransNoListen libXaw.so.7 _XawTextGetSTRING libXaw.so.6 _XawTextGetSTRING libXcursor.so XcursorImageHash libXext.so XShmAttach XShmCreateImage XShmCreatePixmap XShmDetach XShmGetEventBase XShmGetImage XShmPixmapFormat XShmPutImage XShmQueryExtension XShmQueryVersion libXrandr.so XRRConfigCurrentConfiguration XRRConfigCurrentRate XRRConfigRates XRRConfigRotations XRRConfigSizes XRRFreeScreenConfigInfo XRRRates XRRSelectInput XRRSetScreenConfigAndRate XRRUpdateConfiguration libXrender.so XRenderCreateAnimCursor libXt.so _XtCountVaList _XtDefaultWarningMsg _XtVaToArgList colorConvertArgs libGL.so DRI_glXUseXFont XF86DRIQueryExtension __glFreeAttributeState __glXClientInfo __glXCloseDisplay __glXDebug __glXExtensionInfo __glXFlushRenderBuffer __glXFreeContext __glXGetCurrentContext __glXInitVertexArrayState __glXNewIndirectAPI __glXRegisterExtensions __glXRegisterGLXExtensionString __glXRegisterGLXFunction __glXSendLargeCommand __glXSetCurrentContext
