Re: [Devel] FT2 + cygwin

[David Turner]

Hi Karsten,

> 
> There is this runtime DLL issue on Cygwin. Libraries compiled with native
> Windows compilers (especially MSVC) use the MSVCRT.DLL, whereas Cygwin uses
> its own CYGWIN1.DLL. Therefore you can not link MSVC compiled libraries
> against anything compiled with Cygwin's GCC.
> This makes Cygwin somewhat "special" and I _do_ want auto-detection of
> Cygwin, at least from the bash shell.
>
I know about the infamous DLL issue, it's the main reason why I don't
use Cygwin on Windows :-)

Does the Cygwin Bash shell defines the "OS" and "COMSPEC" environment
variables by default. If not, a Win32 system will not be detected and
we'll only need to detect Cygwin in "build/unix/detect.mk"

> When running gmake from Windows command prompt, only Win32 detection should
> take place, because PATH and other things might not be set up correctly for
> Cygwin. Specifying Cygwin as a setup target from Windows command prompt is
> _not_ a good idea, as you would have to guess the PATH to Cygwin tools (i.e.
> from registry entries).
>
Bweurk.. :-( Better to completely forget about Cygwin auto-detection
from the Win command prompt then..

> And then, Cygwin, UWIN and the others are more like UNIX, so UNIX should be
> auto-detected rather than Win32. This is the reason why these packages
> exist...
>
> > As to UWIN, NutCracker, etc.., I don't know enough about them to tell
> 
> On UWIN there's no runtime DLL problem. UWIN uses MSVC as its native
> compiler. However, there are wrapper programs which make calling MSVC much
> more UNIX alike. Configure should auto-detect the compiler wrapper as "cc".
>
> There's GCC, too, for UWIN. It is possible to link MSVC compiled objects
> against GCC compiled ones.
> 
> So auto-detecting UWIN is not so important... but would be very fine.
>
Well, we're not going to add support for this until someone is _really_
interested in it :-) Odes UWIN provides a Bash shell ??

Cheers,

- David