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.
