This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setup: gcc-4.5 compatibility


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]