Philip Hazel wrote:
> The problem with this is that it worked for DLLs with 7.0. I'd rather
> not downgrade the functionality. We know people like Sheri rely on it.
>
> I think we should try to get the declspec correct. Brian said this:
Yes, it would be good to get it right rather than just leaving it out.
> I will work on this shortly and with luck produce -RC4 in a few hours
> time for you to try. I will, of course, have made sure that it works on
> Linux.
Be sure to check out Charles Wilson's reply on the MinGW list, where he
spells out a rough plan:
<
http://marc.info/?l=mingw-users&m=117566038501719&w=2>. It looks
complicated but as far as I can tell most of the bulk is due to the fact
that it supports both "win32/MS toolchain" and "Cygwin/MinGW/libtool"
paradigms, that each have different views of what to define for
compiling static vs. building a DLL.
Another further wrinkle that you might encounter: During testing of the
RC tarball I noticed that when building a Cygwin shared library, libtool
did not pass -DDLL_EXPORT, but it does when building a DLL under MinGW.
I think this is because it was bootstrapped with stock libtool, whereas
I believe that Chuck patches the Cygwin packaged version of libtool to
not do this, i.e. to pass -DDLL_EXPORT on both MinGW and Cygwin. Thus
you run into the sticky situation where the libtool used in the package
has to be created from this patched version of libtool (or CVS HEAD
libtool), otherwise it won't work on Cygwin correctly. Well, actually,
if you leave all the declspec junk conditional on just _WIN32 and not
also on __CYGWIN__, then Cygwin will continue to use the "no declspecs
at all" method that it's always used, and this little issue of
-DDLL_EXPORT will be irrelevant.
Brian
