Andrew Stitcher wrote:
On Thu, 2008-05-29 at 11:32 -0400, Alan Conway wrote:
...
The issue of exported/non-exported symbols is also relevant to the gcc
tool chain as well and gcc supports a notation to control how symbols
are exported from shared object as well. See
http://gcc.gnu.org/wiki/Visibility for the recommended way to do this.
Incidentally doing this is supposed to speed up link times appreciably.
[FYI The gcc syntax is: __attribute__ ((visibility("default"))) for
export and __attribute__ ((visibility("hidden"))) for unexported. There
is no notation for importing into a shared object]
Now THAT is interesting! Steve, I would be interested in a patch with just the
import/export macros so I can give the gcc visibility attributes a whirl. It
looks like that might provide significant build & run time performance benefits
to the gcc build which in turn would benefit the windows build by making gcc
developers care about declspecs.
Not to interrupt your existing plan - if it's convenient for you to get the
declespec work in earlier then that's an interesting option, if not I'll wait
till you're ready with the larger port.
One thing that we need to be careful with is throwing exceptions between
different shared objects, as there are complications here about making
exception classed visible or you'll get crashed on throw, but otherwise
the app will appear to run fine.
Agreed, maybe some sanity scripts to fail the build if it finds any non-exported
exceptions. A simple regexp check might do it, since all our throwable classes
are called .*Exception.
Cheers,
Alan.
