This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Building GFortran
- From: Brian Dessent <brian at dessent dot net>
- To: Angelo Graziosi <Angelo dot Graziosi at roma1 dot infn dot it>
- Cc: fortran at gcc dot gnu dot org
- Date: Tue, 27 Mar 2007 17:01:53 -0700
- Subject: Re: Building GFortran
- Organization: My own little world...
- References: <Pine.OSF.4.21.0703280114520.8268-100000@ax0rm1.roma1.infn.it>
- Reply-to: fortran at gcc dot gnu dot org
Angelo Graziosi wrote:
> The build of GFortran is broken on some system (a few days on Linux, a
> month on Cygwin). The native Windows version was broken from Oct. 2006 to
> March 2007.
The "break" on linux is because the people experiencing problems aren't
using canonical target names. 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.
> All these 'breaks' do not seem related to GFortran itself but to gcc-core.
>
> So my question is: Why to use the gcc-core of same trunk of GFortran ?
>
> For example, if GFortran builds with a version GCC-4.x or a trunk gcc-xxxx
> why not to use those to build current GFC?
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.
> In this way the build of GFC could be 'stable' and the maintainers of GFC
> could get a 'stable' and a 'daily' feedback from the end user Fortran
> programmers, increasing the rate of GFC development.
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.
Brian