qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Status of Qpid port to Windows
Date Thu, 29 May 2008 18:36:36 GMT
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.


View raw message