This is the mail archive of the
mailing list for the Cygwin project.
Re: gcc-2.95.3-4 to mingw
Danny first submitted the patches to the mingw-dvlpr list and I asked
him to submit them here so that they could be included. I was looking
at doing the same thing and Danny's patches were similar to mine. I
wouldn't consider you to be the "mingw gcc maintainer" just the keeper
of the Cygwin/Mingw gcc source.
Ideally, all such changes would be accepted into the main CVS head but
we all know that can take some time.
Christopher Faylor wrote:
> 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:
> >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:
> >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
> >the moment.
> >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.
> http://sources.redhat.com/ http://www.redhat.com/
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com