Marcus Meissner marcus@jet.franken.de writes:
Hi,
Alexandre, is this how to reduce exports? ;)
No, that's only hiding them. It's not a bad thing to do in a second step for functions that really need to be global, but the first step should be to make functions static as much as possible. If we need to have a lot of global functions, it's a sign that the code is not split into files along logical boundaries.
On Thu, 15 Jun 2006 17:28:12 +0200, Alexandre Julliard wrote:
No, that's only hiding them. It's not a bad thing to do in a second step for functions that really need to be global
Can't this be done automatically by winegcc passing -ffunction-visibility=hidden or somesuch?
thanks -mike
Mike Hearn mike@plan99.net writes:
Can't this be done automatically by winegcc passing -ffunction-visibility=hidden or somesuch?
No, we only want the internal functions to be hidden.
On 6/15/06, Alexandre Julliard julliard@winehq.org wrote:
No, we only want the internal functions to be hidden.
Right, so we set default visibility to hidden then change WINAPI and WINAPIV to include __attribute__((visibility(default))). That way only WINAPI declarations are exported.
thanks -mike
Mike Hearn wrote:
On 6/15/06, Alexandre Julliard julliard@winehq.org wrote:
No, we only want the internal functions to be hidden.
Right, so we set default visibility to hidden then change WINAPI and WINAPIV to include __attribute__((visibility(default))). That way only WINAPI declarations are exported.
It's a little harder than that. I experimented with doing this before and it is necessary to apply that same attribute to all of the functions exported from libwine and libunicode.
On 6/16/06, Robert Shearman rob@codeweavers.com wrote:
It's a little harder than that. I experimented with doing this before and it is necessary to apply that same attribute to all of the functions exported from libwine and libunicode.
We're already forcing all exported symbols in those libraries to be visible using the linker script though so I don't see why it'd matter for them?
thanks -mike
"Mike Hearn" mike@plan99.net writes:
On 6/15/06, Alexandre Julliard julliard@winehq.org wrote:
No, we only want the internal functions to be hidden.
Right, so we set default visibility to hidden then change WINAPI and WINAPIV to include __attribute__((visibility(default))). That way only WINAPI declarations are exported.
Sure, but then it's not really useful. The whole point of marking functions explicitly is that it lets you document whether the function is intended to be private or not, and lets you spot functions that should have been static. Doing it all automatically doesn't gain you much, especially since relocations are already resolved at link time by our use of -Bsymbolic.
Now for Winelib it's a different issue, there it would make sense at some point to support setting visibility to hidden and explicitly marking exported functions, so that winebuild could build the import table without requiring a spec file. But even then you have to mark exports explicitly, you can't just redefine WINAPI for that.
-
Alexandre Julliard -
Mike Hearn -
Robert Shearman