Hi Alan, > >> 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.
Separating out just the declspecs would be a tedious job... But I just created QPID-1105 in jira, and the patches for declspecs are part of it. -Steve
