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 15:32:53 GMT
Andrew Stitcher wrote:
> On Tue, 2008-05-27 at 19:27 -0400, Steve Huston wrote:
>> Hi folks,
>>
>> It's been a while and I'm preparing to drop a patch bomb ;-) so I
>> thought this is a good time to give you all an update on the effort to
>> port Qpid to Windows.
>>
>> It's gone pretty well, but ended up needing some refactoring of the
>> AsynchIO stuff - trying to wedge Windows overlapped I/O into the trunk
>> scheme was just too twisted and would cause problems forever. There's
>> some refactoring of the AsynchAcceptor stuff still adviseable but not
>> yet done. With that, the client and common pieces are building on
>> Windows, basically.
> 
> I'm very interested in what you've done here as it probably affects/is
> affected by what I'm currently doing with RDMA.
> 
>> The Windows "shared library" aka a DLL requires specifications of
>> whether symbols are imported or exported. Thus, when building, for
>> example, common, all the class names have to be specified as "export"
>> to make them available to library users (such as client and broker).
>> Conversely, when trying to build against common, the classes have to
>> be marked as "import". I've added the necessary stuff to the common
>> library (and the code generator) to do this. I still have to do it for
>> the client and broker libraries, but it's getting difficult to manage
>> the changes against a moving target on trunk, so here's my plan. I'm
>> updating my trunk on Linux and integrating my changes there and am
>> working to get a clean build and test there, and will then submit the
>> patched and new files via Jira. Hopefully, that can be integrated to
>> get a stake in the ground, and then I and others who've expressed
>> interest in working on the Windows port can jump in and finish adding
>> dll import/export specs and get some real testing underway on Windows.
> 
> 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.

Cheers,
Alan.

Mime
View raw message