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.


View raw message