Anyone want Memcached 1.4.x for Windows?

[Dustin]

I *almost* have it working, but Windows makes me feel absolutely
stupid.

We have:

1) A computer.
2) Buildbot installed (and running).
3) msysgit installed
4) mingw installed
5) libevent 1.4.11 installed
6) A tree that *should* work.

Don't have:

1) Any clue has to how to make Windows do something simple.

I could go into more detail now, but I'll save it for comedy night.

In the meantime, if anyone cares, there should be little to no code
required to get to the next step. Just piece a few things together,
provide me a bit of a clue, and we should be able to emit a Windows
service (or whatever makes sense there).

[Henrik Schröder]

I'm not so sure that mingw is the right way to get it working on windows, the stable versions you can find at http://code.jellycan.com/memcached/ were made to work in Visual Studio, which is the "standard" for making C programs on windows, like it or not. There's a free version of it here: http://www.microsoft.com/express/vc/

Other than that, the main differences between windows and posix is networking and daemonizing. The windows port at jellycan contains helper libraries for that and has integrated them, you should definitely look at that if you haven't already. You should probably also look at how libevent has done it's windows-specific code, I think they have an active windows maintainer, might be a good idea to talk to that person as well?

I'm sorry I can't be of any more help, but I'll gladly cheer you on, I would love to see 1.4 on windows so I can start implementing the binary protocol in my client. :-)


/Henrik

[Dustin]

On Jul 11, 2:42 pm, Henrik Schröder <skro...@gmail.com> wrote:
> I'm not so sure that mingw is the right way to get it working on windows,
> the stable versions you can find athttp://code.jellycan.com/memcached/were
> made to work in Visual Studio, which is the "standard" for making C programs
> on windows, like it or not. There's a free version of it here:http://www.microsoft.com/express/vc/
>
> Other than that, the main differences between windows and posix is
> networking and daemonizing. The windows port at jellycan contains helper
> libraries for that and has integrated them, you should definitely look at
> that if you haven't already.

I've looked at it, but the diff is one very large and coarse
change. It's not something that can be merged and is quite invasive.

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.

That's where it is now -- there's about 18 lines of diff in
memcached.c (and some of that is *removing* platform-specific
ifdefs). The rest of changes are found in a new directory with new
files that provide missing pieces or fit into the platform better.

Now, if VC actually *can* follow a 10-year-old standard to at least
some degree, it might be acceptable. As it is, I'd be happy to have
*anything* work, though.

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.
Besides, we even killed off support for one of our beloved UNIX
platforms for lack of a C99 compiler. :)

> You should probably also look at how libevent
> has done it's windows-specific code, I think they have an active windows
> maintainer, might be a good idea to talk to that person as well?

Perhaps. This is a foreign land to me.

> I'm sorry I can't be of any more help, but I'll gladly cheer you on, I would
> love to see 1.4 on windows so I can start implementing the binary protocol
> in my client. :-)

Hey, you're free to do that anyway. Surely someone uses your client
with a non-Windows server. :)

[Henrik Schröder]

On Sun, Jul 12, 2009 at 04:30, Dustin <dsal...@gmail.com> 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

[Michael Wieher]

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.

--
~ When the great Tao is forgotten, kindness and morality arise.

[Tom D Kat]

I've been casually reading this thread and I tried building memcached-1.4.0 using my 64-bit Linux hosted, 32-bit Win32 targetted MingW cross compiler but the configure script failed trying to see which kind of compilers I had installed, namely the Sun cc compiler:

---------------START--------------------

tom@deathstar:~/build/memcached-1.4.0$ ./configure --host=i686-pc-mingw32
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip
checking for i686-pc-mingw32-gcc... i686-pc-mingw32-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-mingw32-gcc accepts -g... yes
checking for i686-pc-mingw32-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of i686-pc-mingw32-gcc... gcc3
checking how to run the C preprocessor... i686-pc-mingw32-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for icc in use... no
checking for Sun cc in use... configure: error: in `/home/tom/build/memcached-1.4.0':
configure: error: cannot run test program while cross compiling
See `config.log' for more details.
tom@deathstar:~/build/memcached-1.4.0$

-----------------END---------------------

So, if the configure script was tweaked a bit to support cross compiling better, a Linux hosted cross-compiler just might work.

A MingW gcc compiler built to run on Windows should also work even though it probably wouldn't produce as fast or compact an executable as Microsoft's compiler.

Cygwin could also be an option, since it would provide a Unix-like environment on Windows, but I don't know how that would impact performace of memcached on Windows.

Peace...

Tom

[Henrik Schröder]

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

[Tom D Kat]

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

[Dustin]

On Jul 12, 2:12 am, Henrik Schröder <skro...@gmail.com> wrote:

> 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?

If I can, I'd like to actually run the test suite on every build as
well. Trying to get this as close to first-class as possible.

[Dustin]

On Jul 12, 8:19 am, Tom D Kat <tommyd...@gmail.com> wrote:
> I've been casually reading this thread and I tried building memcached-1.4.0
> using my 64-bit Linux hosted, 32-bit Win32 targetted MingW cross compiler
> but the configure script failed trying to see which kind of compilers I had
> installed, namely the Sun cc compiler:

The win32 branch in my github repo has pretty much a separate build
system for Windows bypassing autoconf.

[Michael Wieher]

That is a good idea. I've had code that behaved differently due to
issues running memcahced as a service (and return values if the
service is not started, remembers things incorrectly, etc.) on
different platforms, but I believe that was because of a version
difference.

[Tom D Kat]

Ok.  I actually made some mods to configure.ac to fix the cross compiler issues I ran into and since my last post to the list, I've managed to get the configure script running to the point where I can start compiling stuff.  The other obstacle I ran across was the POSIX thread library requirement, which I got around my locating a Win32 PThreads library.

Since you're not using autoconf in your win32 branch, using a MingW gcc compiler should work just fine for you.

Peace...

Tom

[Dan Wierenga]

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

 

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…)

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.

[Tom D Kat]

Hmmm, sounds interesting.  I've never heard of the SUA.

Thanks for the info!

Peace...

Tom