Re: gcc-2.95.3-4 to mingw

[Christopher Faylor <cgf at redhat 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.

cgf

On Thu, May 17, 2001 at 02:34:10PM +1000, Danny Smith wrote:
>Hello all,
>
>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.
>Refer here:
>http://gcc.gnu.org/ml/gcc-patches/2000-09/msg01139.html  
>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
>http://www.geocrawler.com/archives/3/6013/2000/10/0/4465027/
>
>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
>build,
>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
>difference
>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
>the moment.  
>
>
>I configured like so:
>../gcc-2.95.3/configure  --prefix=/mingw --host=mingw32
>--target=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.
>
>
>Danny
>
>
>
>
>
>_____________________________________________________________________________
>http://messenger.yahoo.com.au - Yahoo! Messenger
>- Voice chat, mail alerts, stock quotes and favourite news and lots more!


-- 
cgf@cygnus.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/