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] > > How does that sound? I'm a touch concerned that it will cause me some merge grief, but we'll have to deal with it sooner or later. Andrew
