This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Building GFortran
- From: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- To: fortran at gcc dot gnu dot org
- Cc: "Angelo Graziosi" <Angelo dot Graziosi at roma1 dot infn dot it>
- Date: Wed, 28 Mar 2007 09:25:26 +0200
- Subject: Re: Building GFortran
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hvALgx6yt+a+ZnZ/zKR9APlNpCg7hhxtX00pKKPk3dI6BIFk7AvymyPRRlSR24Yd1nCuNj37Kae4tclmrPHzO4pjZakVfxYRAUe5zoWFA6h7ZztiwBvpr6airV4UGBdfx+jmJGPWd4GsxMnWds0+3o6nGrESqjLNb9/0bszBOuE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EraOeH2YsFAwtRXEIrYbh48xIBOS/j/i7Ipw6IuOuA7TxXZOWpYo3LhKZ788+EzL2ocRXI1QbBCLsGyNpun0r2Y1txvs1Yk9XGvlyA/iubrp3eUc8hOVNpub6XQPvDRA+PNDOwRH2qAbNFQMu/oBKfLZ+5KxGJF1AbdK1sXfxUk=
- References: <Pine.OSF.4.21.0703280114520.8268-100000@ax0rm1.roma1.infn.it> <4609B071.37A70170@dessent.net>
The "break" on linux is because the people experiencing problems aren't
using canonical target names.
That's not true. Bootstrap for target i386-pc-linux-gnu (which is the
canonical target name) is broken, that's PR31344. It can be worked
around with --disable-decimal-float but it's still a bootstrap
breakage, and I would have liked people to act more quickly about it,
but anyway.
I believe Angelo might be referring in particular to the gfortran
nightly builds provided on the GCC wiki
(http://gcc.gnu.org/wiki/GFortranBinaries). In that case, Angelo,
you'll notice that the builds are working again.
The break on Cygwin is due to problems
with the libc headers (i.e. newlib) using "static inline" and is
technically not a gcc bug, it was just recently exposed by changes in
gcc.
Hum, I'm not sure I can concur with that either. The headers were
written for the old GCC behaviour, so you can't really pretend they
were buggy (they were precisely doing what GCC asked). Implementing
behaviour A for years and have people write code that works with that,
and then switching (without notice) to behaviour B doesn't make it
suddenly a bug in the rest of the world's code.
The split between components is only for the purpose of making people
not have to download source they don't need. They are not actually
separate modules. There code is really one large piece, there is no way
to mix and match bits and pieces from different versions like that. It
would never work, they are too interconnected.
[...]
If you're building from HEAD/4.3 you have to expect regular breakage.
This is a development branch, so it's par for the course.
That part is right. You can have a stable gfortran by having a
released version, or even a snapshot of the 4.2 branch (there are
i686-linux nightly builds of the 4.2 branch available here:
http://fx.coudert.free.fr/gfortran/) You can also have the development
version, which has new features and new bugs, for both GCC and
gfortran.
One more point is that by developing the Fortran front-end along with
the core GCC, we get feedback on the middle-end and back-end bugs
exposed by gfortran much earlier. Off the top of my head, I can quote
at least a dozen middle-end bugs that were exposed by gfortran while
normal bootstrap and regtesting of the C compiler was right. If we
developed the front-end against an older core, every time we'd switch
to a new core we'd discover previously-unknown bugs.
About the specific cygwin issue (the mingw can be worked around, so I
resumed providing my mingw builds), I don't know what it is and where
it happens. Does someone have references?
FX