[Top][All Lists]

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

Re: Detecting the need for -mwin32 in newer cygwin gcc's

From: Robert Collins
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
Date: Thu, 8 Mar 2001 22:49:33 +1100

----- Original Message -----
From: "Alexandre Oliva" <address@hidden>
To: "Charles S. Wilson" <address@hidden>
Cc: "Christopher Faylor" <address@hidden>; <address@hidden>;
Sent: Thursday, March 08, 2001 9:48 PM
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's

> On Mar  8, 2001, "Charles S. Wilson" <address@hidden> wrote:
> Autoconf is about portability across multiple platforms.  If you
> depend on MS-Windows proprietary libraries, there's not much hope for
> portability.  So, why use autoconf, in the first place?

Sorry, this is a little bit stream-of-thought.

Lets take squid which I am spending a fair amount of time hacking on at
the moment. It uses autoconf, for portability. It also uses some fairly
platform specific features of various platforms, when they are available
(ie ethernet MAC acl's are only implemented on Linux.). There are two
sets of things that change from platform to platform: optional features,
and variations in core features (ie SIGNAL support (e.g. the threads
library on Linux swallows a signal used for reconfiguring on other
platforms or squid on linux without threads). Squid is rapidly moving to
a very modular architecture to allow more experimentation/extenstions,
and more platform specific tuning without compromising existing or core
features. (I.e. /dev/poll on *BSD from memory).

> If you don't depend on MS-Windows proprietary libraries, then there's
> no reason for -mwin32.

Having set the stage above, you can see that squid uses autoconf to
detect what features are available, before trying to compile them in,
and that it is very reasonable for the developers to add fine tuned
support for various core parts of squid using the win32 API - over and
above the excellent job cygwin provides. Some examples that I have on my
todo list for squid: service manager support, Overlapped IO support, and
async disk support. Squid is architected to support these, using

> Or am I missing something about the effects of this new -mwin32 flag?

With -mno-win32, older cross platform code that _has non-portable,
non-autoconf_ code in it, will compile as though it's on a pure unix
platform. With -mwin32 that same code will often not compile, because it
has been kludged to work when compiled under MSVC.

That is why the default for gcc is changing, to make porting previously
'natively ported' code easier to port to cygwin with it's comprehensive

To write newer, cross platform code, that can take advantage of some of
the native windows features that cygwin (quite reasonably) doesn't
provide - such as the service manager, autoconf should all programmers
to indicate that they are using native windows features.

I'm not 100% sure that a single macros covers the cases properly:

cygwin, win32
cygwin, nowin32
no cygwin (aka mingw32), win32
no cygwin, nowin32

It seems to me that the developer of a package might want to support
building under cygwin or mingw32 with no win32 support, for a 'true unix
like' build, and also add support for being built with the win32 options
available. On the other hand the end user wants
make test
make install
to produce what the developer would recommend for that platform.

so using GCC='gcc -mwin32' ./configure is unacceptable.

when using gcc -nocygwin, the host should be returned as mingw
, then a pair of macros
which check for the compiller flags needed to get the win32 headers
included/not included respectively cover all the bases (I think).

The developer then does a host check for cygwin/mingw, and then checks
for that ports preferred environment (which the developer chooses as


> --
> Alexandre Oliva   Enjoy Guarana', see
> Red Hat GCC Developer                  address@hidden,}
> CS PhD student at IC-Unicamp        address@hidden,}
> Free Software Evangelist    *Please* write to mailing lists, not to me
> --
> Want to unsubscribe from this list?
> Check out:

reply via email to

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