regex.c not found, but it clearly exists

regex.c not found, but it clearly exists

[NightStrike]

When compiling binutils in a cygwin shell using the mingw binary
release of gcc, I see the following confusing thing:

NightStrike@coolermaster1 /tmp/b6/bu/libiberty
$ make
if [ x"" != x ]; then \
          i686-pc-mingw32-gcc -c -DHAVE_CONFIG_H -g -O2 -I.
-I/tmp/build/binutils/src/libiberty/../include  -W -Wall
-Wwrite-strings -Wstrict-prototypes -pedantic
/tmp/build/binutils/src/libiberty/regex.c -o pic/regex.o; \
        else true; fi
i686-pc-mingw32-gcc -c -DHAVE_CONFIG_H -g -O2 -I.
-I/tmp/build/binutils/src/libiberty/../include  -W -Wall
-Wwrite-strings -Wstrict-prototypes -pedantic
/tmp/build/binutils/src/libiberty/regex.c -o regex.o
gcc.exe: /tmp/build/binutils/src/libiberty/regex.c: No such file or directory
gcc.exe: no input files
make: *** [regex.o] Error 1

NightStrike@coolermaster1 /tmp/b6/bu/libiberty
$ ls -la /tmp/build/binutils/src/libiberty/regex.c
-rw-r--r-- 1 NightStrike None 253K Jul 22  2005
/tmp/build/binutils/src/libiberty/regex.c



As you can see, the file does exist and is nonzero.  It is readable by
user, group, and world.  Why would gcc say it does not exist?

Re: regex.c not found, but it clearly exists

[Brian Dessent]

NightStrike wrote:

> As you can see, the file does exist and is nonzero.  It is readable by
> user, group, and world.  Why would gcc say it does not exist?

You're feeding a POSIX path to a MinGW application.  MinGW applications
have no path translation ability and can only accept Win32 paths.  So
no, the file does not exist in the eyes of i686-pc-mingw32-gcc because
it has no idea what /tmp is supposed to mean.  But 'ls' is a Cygwin app
and knows what /tmp is, so of course that works.

You need to use MSYS if you want this to work, because MSYS does path
translation of command line arguments when invoking MinGW apps.  Cygwin
does not because Cygwin is not intended to work with apps that don't
understand POSIX paths.

This has nothing to do with binutils, so I suggest you follow up on the
MinGW list.

Brian

Re: regex.c not found, but it clearly exists

[Rick Mann]

On Dec 13, 2007, at 11:05 PM, NightStrike wrote:

> When compiling binutils in a cygwin shell using the mingw binary
> release of gcc, I see the following confusing thing:

Let me ask: is regex.c a symlink to the real regex.c? If so, you  
probably created the symlink with Cygwin's ln, but mingw doesn't use  
the Cygwin I/O library, and so can't read the symlink correctly.

I just learned this myself.

I ended up building with Cygwin's GCC.

-- 
Rick

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Brian Dessent wrote:
> NightStrike wrote:
> 
>> As you can see, the file does exist and is nonzero.  It is readable by
>> user, group, and world.  Why would gcc say it does not exist?
> 
> You're feeding a POSIX path to a MinGW application.  MinGW applications
> have no path translation ability and can only accept Win32 paths.  So
> no, the file does not exist in the eyes of i686-pc-mingw32-gcc because
> it has no idea what /tmp is supposed to mean.  But 'ls' is a Cygwin app
> and knows what /tmp is, so of course that works.
> 
> You need to use MSYS if you want this to work, because MSYS does path
> translation of command line arguments when invoking MinGW apps.  Cygwin
> does not because Cygwin is not intended to work with apps that don't
> understand POSIX paths.

Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.

That's a Cygwin program so it understands the POSIX paths, but it 
produced MinGW programs (which don't).

Andrew

Re: regex.c not found, but it clearly exists

[NightStrike]

On 12/14/07, Andrew STUBBS <andrew.stubbs@st.com> wrote:
> Brian Dessent wrote:
> > NightStrike wrote:
> >
> >> As you can see, the file does exist and is nonzero.  It is readable by
> >> user, group, and world.  Why would gcc say it does not exist?
> >
> > You're feeding a POSIX path to a MinGW application.  MinGW applications
> > have no path translation ability and can only accept Win32 paths.  So
> > no, the file does not exist in the eyes of i686-pc-mingw32-gcc because
> > it has no idea what /tmp is supposed to mean.  But 'ls' is a Cygwin app
> > and knows what /tmp is, so of course that works.
> >
> > You need to use MSYS if you want this to work, because MSYS does path
> > translation of command line arguments when invoking MinGW apps.  Cygwin
> > does not because Cygwin is not intended to work with apps that don't
> > understand POSIX paths.
>
> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>
> That's a Cygwin program so it understands the POSIX paths, but it
> produced MinGW programs (which don't).

Are programs compiled in this fashion identical to programs that are
compiled with the actual i686-pc-mingw-gcc program?

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

RE: regex.c not found, but it clearly exists

[Dave Korn]

On 02 January 2008 12:42, Andrew STUBBS wrote:

> NightStrike wrote:
>>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>> 
>>> That's a Cygwin program so it understands the POSIX paths, but it
>>> produced MinGW programs (which don't).
>> 
>> Are programs compiled in this fashion identical to programs that are
>> compiled with the actual i686-pc-mingw-gcc program?
> 
> Since nobody more qualified has responded ...
> 
> I don't know if they are perfectly identical, but they certainly have
> the same general properties. That is, in order to build a UNIX program
> you have to apply the exact same patches as you would for the MinGW
> compiler.

  This is basically it, but there are some problems.  The -mno-cygwin flag and
the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
The major purpose for which they are packaged is so that you can rebuild the
cygwin dll itself from within the cygwin environment.  It's not really
intended for general cross-development, and although it'll just about do,
there is a problem: it doesn't correctly switch over /all/ the default search
paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
-mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
searches the cygwin compiler-specific include dir

/usr/lib/gcc/i686-pc-cygwin/3.4.4/include

when it should be looking in:

/usr/lib/gcc/i686-pc-mingw32/3.4.4/include

  I don't know - and couldn't say for sure without doing a thorough audit -
how serious this could be, but from running a very quick diff over it, I can
see that it might in particular affect C++.  (It could easily break passing
std::strings across DLL boundaries, which cygwin has some custom mods to the
c++ stl header files relating to).

> Note that you must have installed the right Cygwin package for it to
> work - it uses a different set of libraries in -mno-cygwin mode.

  Yes, the packages required for -mno-cygwin are w32api and mingw-runtime
IIRC.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

Dave Korn wrote:
>   This is basically it, but there are some problems.  The -mno-cygwin flag and
> the cross-compile mode of the cygming-targeted compiler are somewhat kludgey.
> The major purpose for which they are packaged is so that you can rebuild the
> cygwin dll itself from within the cygwin environment.  It's not really
> intended for general cross-development, and although it'll just about do,
> there is a problem: it doesn't correctly switch over /all/ the default search
> paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc
> -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still
> searches the cygwin compiler-specific include dir
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
> 
> when it should be looking in:
> 
> /usr/lib/gcc/i686-pc-mingw32/3.4.4/include
> 
>   I don't know - and couldn't say for sure without doing a thorough audit -
> how serious this could be, but from running a very quick diff over it, I can
> see that it might in particular affect C++.  (It could easily break passing
> std::strings across DLL boundaries, which cygwin has some custom mods to the
> c++ stl header files relating to).

We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb 
and a few other bits and pieces. I've never had any trouble with search 
paths that I couldn't blame on the build system, although no doubt there 
are some pit-falls to be had.

Obviously there are a number of patches required to build all those 
utilities on windows. We also have a few patches to make the tools 
understand /cygdrive paths in a limited way - it won't build the target 
libraries without.

We used to target Cygwin, rather than Windows, but that meant that all 
our customers also had to use Cygwin, and there were version mismatch 
problems to overcome.

Andrew

P.S. Sorry about the multiple posts - I've received a notification from 
the mailserver saying that it's having trouble sending the message, but 
there doesn't seem to be any way to tell it not to bother.

Re: regex.c not found, but it clearly exists

[Andrew STUBBS]

NightStrike wrote:
>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc.
>>
>> That's a Cygwin program so it understands the POSIX paths, but it
>> produced MinGW programs (which don't).
> 
> Are programs compiled in this fashion identical to programs that are
> compiled with the actual i686-pc-mingw-gcc program?

Since nobody more qualified has responded ...

I don't know if they are perfectly identical, but they certainly have 
the same general properties. That is, in order to build a UNIX program 
you have to apply the exact same patches as you would for the MinGW 
compiler.

Note that you must have installed the right Cygwin package for it to 
work - it uses a different set of libraries in -mno-cygwin mode.

Andrew