This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Apparent thinko in closures.c causing GCC bootstrap failure on Cygwin
- From: Andrew Haley <aph at redhat dot com>
- To: Timothy Wall <twalljava at dev dot java dot net>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, libffi-discuss at sourceware dot org, Java Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Jun 2009 15:09:13 +0100
- Subject: Re: [PATCH] Apparent thinko in closures.c causing GCC bootstrap failure on Cygwin
- References: <4A4A024B.email@example.com> <19015FFA-2DB6-4825-8881-D0D492279470@dev.java.net>
Timothy Wall wrote:
> On Jun 30, 2009, at 8:17 AM, Dave Korn wrote:
>> Some minor fallout resulting after the libffi merge. The code in
>> is currently structured like this:
I don't think this is anything to do with the merge, it's Timothy's
> When compiling for windows, there shouldn't be any mmap/munmap
> references at all. While cygwin may supply some version of these,
> dlmalloc defines w32mmap/w32unmap which directly calls the appropriate
> routines for windows when WIN32 is defined (which I believe is always
> the case for the mingw compiler).
> Apparently the cygwin build is defining macros differently than
> -mno-cygwin (which is what I use for w32/w64), resulting in extant
> references to mmap/munmap.
> Have you run the tests on a system with DEP enabled (System control
> panel->Performance Options->Data Execution Prevention)? That's likely
> the only place they'd fail if mmap isn't set up correctly. Prior to the
> w64 patches the dlmalloc stuff never enabled the w32 mmap equivalents,
> so it was always using vanilla malloc for closures.
So can we get back to the status quo ante for Cygwin?