qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Status of Qpid port to Windows
Date Thu, 29 May 2008 16:19:21 GMT

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.

Andrew



Mime
View raw message