Hmmm, sounds interesting. I've never heard of the SUA. Thanks for the info!
Peace... Tom On Mon, Jul 13, 2009 at 12:35 PM, Dan Wierenga <[email protected]>wrote: > Just out of curiosity, has anyone looked at building it with the > Subsystem for Unix Applications (Windows SUA)? It seems like this type of > thing is exactly why the SUA is supported by Microsoft. > > http://technet.microsoft.com/en-us/library/cc779522(WS.10).aspx<http://technet.microsoft.com/en-us/library/cc779522%28WS.10%29.aspx> > > > > On my SUA installation (Vista Enterprise SP1), ./configure works fine, and > make churns away happily until it figures out I don’t have libevent > installed. Libevent has issues during make but I’m not a C programmer so > figuring out what’s wrong with libevent is beyond me. > > > > -Dan (first-time poster, long-time reader…) > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Tom D Kat > *Sent:* Sunday, July 12, 2009 8:51 AM > *To:* [email protected] > *Subject:* Re: Anyone want Memcached 1.4.x for Windows? > > > > 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. > > > > > > > This email and any files included with it may contain privileged, > proprietary and/or confidential information that is for the sole use > of the intended recipient(s). Any disclosure, copying, distribution, > posting, or use of the information contained in or attached to this > email is prohibited unless permitted by the sender. If you have > received this email in error, please immediately notify the sender > via return email, telephone, or fax and destroy this original transmission > and its included files without reading or saving it in any manner. > Thank you. > >
