From: "Bernard Delmée" Date: 2001-10-05T08:19:50+09:00 Subject: [ruby-talk:22105] Re: Flogging a live Window "Eli Green" wrote: > Mingw and VC can apparently live together in peace and harmony. I have gotten > ruby to compile under Visual Studio, producing a .DLL of the core Ruby stuff > and a .exe linked to that DLL. This is how Python and Perl do it, with obvious > reasons/advantages. Except for the convenience of using the IDE, this is already supported by the standard ruby distro: if you run win32/configure.bat, then nmake, you'll end up with 'mswin32-ruby16.dll' and 'ruby.exe' > There is one problem ... and if there are any Windows people with a solution > to this out there, I'd love to hear it ... exported symbols in a Windows DLL > need that damned __declspec(dllexport) in front of them! And I sure as hell > don't want to be the one who has to insert that in front of every public > function in the ruby source ... so if somebody knows how to force LINK.EXE to > export every symbol (like ld does), that'd be very welcome information. The alternative is a '.def' file. Again, running the standard MSVC build proc will give you a 'ruby.def' file. You can use that as spec for your DLL. Not sure if it exports _every_ symbol. It'd obviously be cleaner if it did not. On a more general note: I agree that being able to use either vc or mingw to build ruby and extensions would be nice. Platform-specific modules requiring recents SDK's and stuff would be more likely developed by programmers equipped with VC, whereas the occasional *nix port can be realised through mingw. Neat. Now, did you find the time to have a look at the performance issue I raised earlier? Both vc and mingw seemed to run significantly slower than cygnus in that test case. Granted, this is but one example, but since nobody has countered it, or provided proof of cygwin instability for that matter, I cannot help but wonder why the rush away from the best performing build... Thanks a lot for the effort and the insight gained in a tricky matter, Regards, Bernard.