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--------------------
t...@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.
t...@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
On Sun, Jul 12, 2009 at 8:10 AM, 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.
>
