Re: MinGW build instructions

[Christopher Faylor <me@cgf.cx>]

On Wed, May 11, 2005 at 09:41:35PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 11 May 2005 12:11:53 -0400
>> From: Christopher Faylor
>> 
>> You don't have to install 700MB of cygwin to get things working.  You
>> should be able to get away with just installing the bits that you need +
>> the mingw compiler.  Or, it is possible that a i686-pc-mingw32-gcc
>> wrapper like:
>> 
>> #!/bin/sh
>> exec gcc -mno-cygwin "$@"
>> 
>> may "just work" with the cygwin version of gcc.  The -mno-cygwin option
>> to gcc actually uses the mingw headers and libraries.  Unfortunately,
>> there is a problem with cygwin-bleedover for libraries, though, so
>> you have to be careful not to specify any libraries on the command
>> line which exist on cygwin but not in mingw.  This is something that
>> I keep meaning to fix in gcc/binutils...
>
>Thanks for the info.
>
>However, what is needed are precise instructions based on actual
>experience.  If I were someone who needs for the first time compile a
>GNU package on Windows, it would not help me to know that
>such-and-such setup ``might just work''.

Yes, I know that, Eli.  These were hints for someone who might want to
try it.  They were not intended as step-by-step instructions since,
obviously I can't provide those.  I thought that maybe they'd be
useful for someone who was interested in trying this.

>Also, the configuration that you suggest: some part of Cygwin and the
>MinGW compiler, will probably suffer from incompatibilities due to
>Cygwin file names that the MinGW compiler probably doesn't understand,
>symlinks that the utilities such as ln support, but the MinGW compiler
>might not, etc.

I don't see why.  You just install the mingw compiler and put it in your
path.  There obviously won't be any cygwin symlinks in the mingw compiler
tar ball.

>I didn't try MSYS, but it sounds that they did resolve these problems
>in a more satisfactory manner.

I doubt it.  MSYS's claim to fame is that you don't have to use the
cygwin mount table.  AFAIK, it does nothing special with symlinks.  Msys
would not have problems with cygwin bleed over I mentioned since
there wouldn't be any cygwin components.

OTOH, as I mentioned, AFAIK all of MSYS's components lag cygwin in terms
of bug fixes and frequency of updates.

It's odd that you apparently don't like my not being specific enough but
then go on to postulate general problems with things that you haven't
tried.  But, regardless, I was just offering opinions.  It seems like my
offering information has now gotten me into YA debate.  I think I'm
learning some kind of lesson here.

>So I don't really understand why you don't like their alternative.  Is
>it known to have some serious problems?

How much would you like someone saying "I've got this new version of
tools that I've called CFGPP" if the tools were a repackaging of DJGPP
with some patches?  What if the person involved in CFGPP was
occasionally apparently fixing bugs but not pushing them back to DJGPP?
How about if the CFGPP web site made no mention of the fact that it was
95% DJGPP with some changes?  How about if CFGPP binaries started
showing up which played badly with DJGPP and people started asking you
to fix DJGPP so that it worked better with CFGPP?  How about if people
started asking CFGPP questions in the DJGPP mailing lists?

These are standard problems with a fork and my reaction, as the project
lead for Cygwin, is a typical reaction to a fork.  I don't know if MSYS
has serious problems.  I haven't heard of any but I'm not going to
endorse it because I use another alternative.

cgf