This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: setup: gcc-4.5 compatibility
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
- Date: Thu, 22 Jul 2010 22:50:27 -0400
- Subject: Re: setup: gcc-4.5 compatibility
- References: <1279229264.7380.21.camel@YAAKOV04>
On 7/15/2010 5:27 PM, Yaakov (Cygwin/X) wrote:
> My test case for the mingw toolchain is, of course, setup.exe. I have
> uploaded test builds of all mingw-* prereqs here:
>
> ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
>
> setup-gcc45.patch contains the changes necessary to compile and link
> with mingw-gcc-4.5. However, the resulting setup.exe promply SEGVs in
> RtlInitUnicodeString@8. The problem is centered around the autoload
> code, because if you circumvent autoload and link directly against those
> APIs, then the resulting binary works. This can be demonstrated by
> applying setup-no-autoload.patch on top of the first patch, then:
>
> make CPPFLAGS=-DSETUP_NO_AUTOLOAD LIBS='-lmingw32 -lntdll -lwininet'
>
> The reason for the crash is beyond me. Hopefully this will be enough
> for someone to help figure it out.
As noted here:
http://cygwin.com/ml/cygwin-apps/2010-07/msg00175.html
I was able to build setup.exe using i686-pc-mingw32-gcc and only
setup-gcc45.patch (that is, without setup-no-autoload.patch) and it worked.
The key difference, I think, is that all of the
mingw-{zlib,bzip2,xz,gpg-error,gcrypt} packages, and setup itself were
compiled with -mms-bitfields.
In any event, my new versions of the mingw-{...} packages are all built
as closely as I can make them, to the way the old versions did it. (This
made the cygports pretty doggone ugly, but they are all at least
somewhat improved over the earlier gcc3-mno-cygwin versions!)
It could be that -mms-bitfields is a red herring (and building
*everything* universally with -mnoms-bitfields would work just as well)
-- and the real culprit here is that my old cygports and my new ones are
both doing something magic that Yaakov's simpler implementations don't.
Maybe. My attitude is, keep 'em ugly, since ugly works. And then, we
can later try to make 'em cleaner -- one at a time, giving cgf or other
interested parties time to yell "STOP" if a change breaks setup.
--
Chuck