Re: [PATCH] Export symbol lists on Linux
On Wed, Oct 15, 2003 at 11:00:23PM +0200, Jakub Jelinek wrote: On Wed, Oct 15, 2003 at 03:06:46PM -0400, David Dawes wrote: 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. No idea about Cygwin and OS2, for now I've just used it in 2 places in GL-def.cpp but it can be expanded. Attached is a first version of the patch against CVS HEAD, which builds, covers all undefined symbols by XFree86 programs/shared libraries which used to be satisfied by the XF86 shlibs and similarly all 5870 programs/shlibs on my disk. The lnxLib.rules changes should work both with old binutils (where version script simply will not be used and all symbols exported) and newer binutils (2001-12-18 and later) where it will be used. I think it is more important first to make sure there are no symbols which ought to be exported but are not than to make sure that no symbols which are not supposed to be exported are visible. That way we can ensure XFree86 will continue working; in later steps symbols can be removed from the export libs as they are analyzed. I've made lots of *-def.cpp changes keyed from __linux__ for now (well, typically OS2 and linux has very similar export sets), because I have no idea what OS2 and Cygwin needs/doesn't need to export and don't want to break them. Also, X11-def.cpp apparently contains two sets of symbols, one for !OS2 !Cygwin !linux (no idea what platform which uses *-def.cpp is it), one for those 3. Either one set should be killed if it is unused, or merged with the other set. The !OS2 !Cygwin symbols appear to have been in the version of these files imported from X11R6.0. I don't know their origin, but they might have been for Win32 builds. The lists need to be divided into the API-defined symbols, platform-independent exceptions that applications and/or other libraries appear to be using, and platform-specific exceptions determined from examination of the relevant library source (some of the symbols in the existing -def.cpp files marked as platform specific are not). We definitely don't want to keep multiple lists. Some symbols that are currently commented out in a platform-specific way, like: -#ifndef __UNIXOS2__ +#if !defined(__UNIXOS2__) !defined(__linux__) XftDrawCorePrepare #endif should be removed because they no longer exist. That's where checks against the API specs (when they exist) and the public library headers and source code are needed. Has anyone done a comparison of these lists against the API specs yet? IMO this is the most significant part of this exercise, combined with the data you have collected from a set of existing applications. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Export symbol lists on Linux
I wouldn't be opposed to just wiping out the #ifdef __CYGWIN__ stuff and starting fresh with a test build. I can always put back any platform-specific #if's that turn out to still be valid. Harold David Dawes wrote: On Wed, Oct 15, 2003 at 11:00:23PM +0200, Jakub Jelinek wrote: On Wed, Oct 15, 2003 at 03:06:46PM -0400, David Dawes wrote: 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. No idea about Cygwin and OS2, for now I've just used it in 2 places in GL-def.cpp but it can be expanded. Attached is a first version of the patch against CVS HEAD, which builds, covers all undefined symbols by XFree86 programs/shared libraries which used to be satisfied by the XF86 shlibs and similarly all 5870 programs/shlibs on my disk. The lnxLib.rules changes should work both with old binutils (where version script simply will not be used and all symbols exported) and newer binutils (2001-12-18 and later) where it will be used. I think it is more important first to make sure there are no symbols which ought to be exported but are not than to make sure that no symbols which are not supposed to be exported are visible. That way we can ensure XFree86 will continue working; in later steps symbols can be removed from the export libs as they are analyzed. I've made lots of *-def.cpp changes keyed from __linux__ for now (well, typically OS2 and linux has very similar export sets), because I have no idea what OS2 and Cygwin needs/doesn't need to export and don't want to break them. Also, X11-def.cpp apparently contains two sets of symbols, one for !OS2 !Cygwin !linux (no idea what platform which uses *-def.cpp is it), one for those 3. Either one set should be killed if it is unused, or merged with the other set. The !OS2 !Cygwin symbols appear to have been in the version of these files imported from X11R6.0. I don't know their origin, but they might have been for Win32 builds. The lists need to be divided into the API-defined symbols, platform-independent exceptions that applications and/or other libraries appear to be using, and platform-specific exceptions determined from examination of the relevant library source (some of the symbols in the existing -def.cpp files marked as platform specific are not). We definitely don't want to keep multiple lists. Some symbols that are currently commented out in a platform-specific way, like: -#ifndef __UNIXOS2__ +#if !defined(__UNIXOS2__) !defined(__linux__) XftDrawCorePrepare #endif should be removed because they no longer exist. That's where checks against the API specs (when they exist) and the public library headers and source code are needed. Has anyone done a comparison of these lists against the API specs yet? IMO this is the most significant part of this exercise, combined with the data you have collected from a set of existing applications. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
