freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Devel] FT2 + cygwin


From: Fleischer, Karsten (K.)
Subject: RE: [Devel] FT2 + cygwin
Date: Wed, 13 Dec 2000 05:46:03 -0500

Hi David,

> I think that detecting Cygwin is _not_ so important. After 
> all, using a
> specific setup target, as in "make setup cygwin", should be 
> enough when
> run from the Windows command shell.
> 
> What could be fun however is to auto-detect Cygwin from the Bash
> shell on Win32 though.. and this is certainly easy to do..

Hmm, I'll try to explain...

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

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.

Karsten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]