----- Original Message -----
From: "Wu Yongwei" <adah@...>
Sent: Wednesday, June 26, 2002 10:12 AM
Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support
> Hi, Danny and Earnie,
> You hit me in the right open-source way. Yes, you have the right to do
> you think appropriate and I have the right to ... but....
> It is really a shame of me to confess that I did not succeed in building
> yet. I started to do so yesterday (a shame, too, not having tried to do it
Did you try building GCC under Cygwin or MSYS? I just tried building
gcc-2.95.3-20011106 under MSYS and I came to a problem with symbolic links
(sigh). The problem is that the configure script does this (in
ln -s ../stage1 stage1
Since ../stage1 does not exist yet at this point, MSYS ln fails (but
unfortunately the configure script ignores the error). Apparently the build
process has other mechanisms for systems that don't have symbolic links, but
configure thinks that "ln -s" works so it doesn't attempt any alternatives.
I guess I could temporarily remove the 'ln' command but is there a nicer way
to make this work? The reason I haven't noticed this before is because the
GCC 3.1 build process doesn't use symlinks in this way.
> As I argued bitterly earlier, Danny "might" easily spend one day
> incorporating most of the fixes, while I was still struggling for the
You'll only learn by trying :).
> OK, it is my problem. I will dig more into the GNU auto* tools and so on
> when the current project of our company is over. We do things on Windows
> Linux, and I often test code with every compiler in hand, MSVC, GCC, and
> sometimes Borland C++ Compiler 5.5.1. We don't use auto* tools. In fact, I
> don't like them very much. I think supporting multiple platforms directly
> code like STLport is a better idea. And I do not have many platforms to
> support and test. -- Though, I will spend time on the GNU tools later. I
> have been frustrated enough by them. It's time to conquer them.
If your problem is not the same as mine, you should probably explain it in
case it is a simple mistake that you will waste time investigating.
> Danny, is it possible that you limit the time to fix the old gcc (say, one
> day) and then release an enhanced version? It is not necessary that ALL
> are fixed. It is meaningful that it is a more stable and more bug-free
> version than all previous ones. Of course, if it is not as stable as GCC
> 3.1, do not do it.
> Best regards (and forgive my follies),
> Wu Yongwei
BTW, what bugs have been fixed since the latest Mingw release of GCC 2.95,
apart from this new fastcall one? I assume you are talking about