Yeah, that DLL provides the Unix "environment" the executable would need to execute.
I would also agree going with MingW on Windows would be better than Cygwin. I believe a MingW compiler on Windows would basically be a Windows-native gcc compiler and supporting toolchain. Then, it should be a matter of running make (GNU make might be needed) to build memcached. Peace... Tom On Sun, Jul 12, 2009 at 8:36 AM, Henrik Schröder <[email protected]> wrote: > I was under the impression that if you compile under cygwin, you get a > dependancy to their dll, and exactly that problem is what mingw solves, by > allowing you to compile executables without such a dependency. As someone > who runs a bunch of memcached servers under windows, I'd be skeptical about > a cygwin version and would much prefer one without such a dependency. > > > /Henrik > > > On Sun, Jul 12, 2009 at 17:10, Michael Wieher <[email protected]>wrote: > >> >> I'd look into cygwin as well as mingw if I were trying to hack a >> recent version of memcached to work on a M$ box. >> >> however, there are older versions which behave somewhat badly, but do >> work, on windows. >> >> On Sun, Jul 12, 2009 at 4:12 AM, Henrik Schröder<[email protected]> >> wrote: >> > On Sun, Jul 12, 2009 at 04:30, Dustin <[email protected]> wrote: >> >> >> >> My understanding (and I can't find anything to the contrary -- MS's >> >> site is just awful an makes it quite difficult to find a simple >> >> answer) is that VS doesn't support C99. The jellycan diff shows a few >> >> areas where valid C99 code was modified for C89 compliance. >> >> >> >> Supporting Windows is difficult and expensive, but there was one >> >> very specific constraint that I'd placed on the porting effort to >> >> ensure it would be acceptable and maintainable: >> >> >> >> A new platform port must touch the existing code as absolutely >> >> little as possible. >> > >> > Fair enough. Visual Studio doesn't support C99, and it seems they won't >> > support it in the near future anyway. You can apparently switch to >> Intel's >> > compiler in visual studio, but that's getting as non-standard as using >> > mingw, so if that approach works better for you, go for it. I remember >> > trying to compile memcahed way back using mingw, but failing on the >> > platform-specific parts that just didn't work under windows. >> > >> > Anyway, there seems to be a mingw compiler for Linux, so you could >> actually >> > do the work in your preferred environment but use the cross-compiler >> > instead, and then just test the resulting windows exe on your windows >> > machine. I dunno, maybe that approach helps with your problems? >> > >> >> >> >> I hope I don't sound too unwilling to compromise, but as it is we >> >> can't get anyone to help support a porting effort, so putting more >> >> onus on the existing development community, most of whom probably know >> >> Windows about as well as I do, is unreasonable at this point. >> > >> > That's fine, I really wish I could be of more help, but I'm really not a >> C >> > programmer, and I agree, windows modifications have to be kept as >> > unobtrusive as possible so that you can continue churning out new >> versions >> > without really touching the windows part, or having to worry about it. I >> > also looked at the patches for the windows versions of 1.2.5 and 1.2.6, >> and >> > they are pretty substantial. :-/ >> > >> >> >> >> Hey, you're free to do that anyway. Surely someone uses your client >> >> with a non-Windows server. :) >> > >> > Well, the problem is that I don't have a non-windows machine that I can >> run >> > it on. :-) >> > >> > >> > /Henrik >> > >> >> >> >> -- >> ~ When the great Tao is forgotten, kindness and morality arise. >> > >
