This is the mail archive of the
mailing list for the Cygwin project.
Re: gcc-2.95.3-4 to mingw
- To: cygwin-apps <cygwin-apps at cygwin dot com>
- Subject: Re: gcc-2.95.3-4 to mingw
- From: Christopher Faylor <cgf at redhat dot com>
- Date: Thu, 17 May 2001 03:01:35 -0400
- References: <email@example.com>
- Reply-To: cygwin-apps at cygwin dot com
Hmm. I'm not sure exactly how I feel about these patches.
I have stated on several occasions that I don't really want to be
responsible for mingw considerations, being the cygwin maintainer and
all. Despite this fact, I have been trying to get -mno-cygwin working
as well as possible. That's primarily just to stop the cygwin mailing
list whining, though.
I'm afraid that if I accept these changes, I'll become the de facto
mingw gcc maintainer. I'm not sure that that is something that I
want to do.
Is there a mingw gcc maintainer, now? Is it Earnie? If so, I'd like
to get their opinion on this.
On Thu, May 17, 2001 at 02:34:10PM +1000, Danny Smith wrote:
>Attached diff file are my changes to cygwin's gcc-2.95.3-4 src to get
>it to build under mingw. I have also built from FSF gcc-2.95.3
>(release) source with similar set of patches (on top of Mumits Jan 2000
>diffs), but I thought keeping in sync with cygwin version would have
>advantages as far as maintenance and testing. I have additional gcc
>patches that I would like to add to both cygwin and mingw, which is
>another reason for me wanting to sync gcc src.
>These are the main differences to cygwin version
>libio _IO_pos_t/_IO_off_t type mismatch: These were necessitated by
>the type mismatches between header files and implementation files.
>It is only a problem with msvcrt version of mingw because in crtdll
>version, _IO_pos_t and _IO_off_t are same basic type. Ditto for cygwin.
> In mingw, the former resolves to long long, the latter long, as per
>resp. C runtime types.
>__gthread_getspecific steps on GetLastError: refer here
>One other little bit, a recurring problem with sys_nerr and
>sys_errlist and dllimport in libiberty/strerror.c. This should
>probably be sent to libiberty; I haven't included in ChangeLog.
>I haven't done much testing of above changes with this particular
>but they have not caused any problems since initial testing with 2.95.3
>prerelease 1 in Jan (I think) and release in March. The main
>between my prior builds (which I have tested extensively) and this is:
>config/i386/cygwin.h: Recent changes to this get rid of use of builtin
>specs to accomodate mno-cygwin-all search dirs are specified in specs
>file. Perhaps that could be done for mingw as well, but the way I have
>built is to use the default builtin specs as in prior mingw releases.
>I've put a guard in so that cygwin's undefs don't get applied to a
>native mingw build.
>DIR_SEPARATOR: make '/' the default for mingw, like cygwin.
>version.c: insert mingw into the version string. I tried to use an
>#ifdef __MINGW32__ here to get distinct version string for mingw vs
>cygwin but that breaks the sed script in configure. The 'cygwin-mingw'
>bit of the string won't do of course, but is the last of my concerns at
>I configured like so:
>../gcc-2.95.3/configure --prefix=/mingw --host=mingw32
>--disable-nls --enable-threads=win32 --enable-languages=f77,c++
>and built like so:
>make "CFLAGS=-O2" bootstrap
>This build, of course, will provide the mingw-extra bits for
>the cygwin -mno-cygwin folk.
>http://messenger.yahoo.com.au - Yahoo! Messenger
>- Voice chat, mail alerts, stock quotes and favourite news and lots more!
firstname.lastname@example.org Red Hat, Inc.