writes:
> On Sun, 2010-01-03 at 12:55 -0800, Kristian Høgsberg wrote:
> > On Sun, Jan 3, 2010 at 3:24 PM, José Fonseca <jfons...@vmware.com> wrote:
> > > On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote:
> > >> 2010/1/2 Chia-I Wu <olva...@gmail.com>:
> > >> > On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote:
> > >> >> We have all functions that need to be visible marked with PUBLIC and
> > >> >> this is trimming around 4% off the DRI driver .so size.
> > >>
> > >> This would have to be checked on Windows. I think the x86 dispatch
> > >> code is sensitive to the Windows calling conventions implied by
> > >> GLAPIENTRY.
> > >
> > > Brian is right.
> > >
> > > GLAPI controls symbol visibility, both on unices (i.e.,
> > > _attribute__((visibility("default")))) and windows (i.e.,
> > > _declspec(dllexport).
[snip]
> > Ok, from all this I didn't see anything against enabling
> > -fvisibility-hidden by default so I've committed the patch. Also, the
> > _mesa_* entrypoints are only GLAPIENTRY, not GLAPI, so they are
> > already hidden.
>
> FWIW I also think that-fvisibility-hidden by default is a good a thing.
[snip]
I think an export map is a better way to handle visibility in libGL's
case. One will eventually have to go down the road of annotating every
function to note which symbols are exported or not. Most symbols will
not be.
OpenGL's symbols are fairly standardized, sans new revisions and
extensions and the like. Therefore generating the export map is
trivial. Symbol visibility is most useful with C++ libraries [1],
where features like templates and symbol mangling make generating such
a table into a nontrivial operation.
I've started work on this [2], but haven't jumped back to it since
that email. That work was started because I noted that the existing
symbol hiding strategy (i.e. based on GLAPIENTRY / GLAPI, I'd guess?)
was letting too many symbols through. I believe we'll get a lower (0?)
`false positive' rate by using a table of exported functions.
I also think this will be easily applicable to MSVC [3]; the
aforementioned ([2]) not-yet-existent python script just needs to
generate slightly different output on Windows.
-tom
[1] http://gcc.gnu.org/wiki/Visibility
[2] http://old.nabble.com/-PATCH--RFC%3A-ABI-cleanup-for-libGL.-td26907236.html
[2] http://msdn.microsoft.com/en-us/library/34c30xs1.aspx
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
