On Thu, Oct 09, 2003 at 09:01:15PM -0400, David Dawes wrote:
> >Well, both version script and __attribute__((visibility ("hidden")))
> >can be used at the same time.
> >Anonymous version script works in 2001-12-18 and later binutils
> >and AFAIK in Solaris linker. No idea about other arches.
> >If you think we should list all exported symbols, then maybe we
> >could introduce .sym (or .api) files for each library which would list
> >exported symbols one per line and Imakefile hacks to generate version
> >scripts/whatever else on the fly and use it during linking.
>
> That sounds like a good approach.
>
> There are two ways that this is already done for some platforms. OS/2
> and Cygwin use files like X11-def.cpp to list the exported symbols.
> Those lists might be a good starting point, but I suspect that more
> symbols are exported than are documented in the API specs.
>
> Also, X11R6.3 added export description files (like libX11.elist), together
> with scripts for a few platforms like Solaris, HPUX and AIX to process
> them. The .elist files are only provided for libX11 and libXt, and they
> simply export all globals. I don't know if the basic mechanism is worth
> reusing -- you should look at it and see what you think. They don't
> provide any useful information about what symbols should be exported
> for each library though.
I'd say it would be better to reuse *-def.cpp files (didn't know something
like that existed).
They are preprocessed, so it is easy to add __linux__, whatever else,
also arch specific symbols, whatever necessary.
Transforming *-def.cpp files to anonymous version scripts should be trivial,
whether done in lnxLib.rules, sunLib.rules or some special script.
Given that there are just a handful of -shared links in whole XFree86 build,
perhaps the rule can (in lnxLib.rules) first check whether ld actually
supports anynymous version scripts and only use them if it does.
> >Second thing is how to define Imakefile macros which will enable
> >__attribute__((visibility ("hidden"))) and/or version scripts.
> >Should they be just user settable, defaulting to no, or should
> >imake do the autodetection (for that it needs an autoconf like
> >test, since e.g. even when you have GCC 3.3 and later, still
> >visibility attribute doesn't have to be supported if that GCC
> >was compiled against old binutils, etc.)?
>
> What happens if you use the visibility attribute with a gcc 3.3 that
> doesn't have it enabled? If it's simply ignored, then it shouldn't be
> an issue. Otherwise, is there no pre-defined macro so that you can test
> for it in the source?
There is no predefined macro, the attribute is ignored if not supported,
but with a warning:
If it is GCC which has visibility attribute support but that attribute is
not supported in its particular configuration (linked against old binutils,
not using binutils or architectire which doesn't support it), you get:
"visibility attribute not supported in this configuration; ignored"
warning, if it is GCC without visibility attribute support (e.g. older
releases), you get:
`visibility' attribute directive ignored
warning.
I don't know how much XFree86 relies on being warning free.
GCC 3.3+ on Linux will typically be configured such that this attribute
is supported and give no warning (dunno about *BSD etc.), so it would issue
warnings just in a few configurations.
Jakub
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
