#1029 Fix list of supported build utilities
Metadata
| Property | Value |
|---|---|
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jan 23, 2012 17:43 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Jul 7, 2012 14:33 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jul 7, 2012 14:33 |
| Closed in version | 2.2 |
| Resolution | Fixed |
| Comment |
Description
http://www.dune-project.org/doc/installation-notes.html claims support for gcc-3.4.1 and several icc versions which are probably never tested. Which of those are actually really supported?
Activity
Please enter the compiler and build tools we have to / want to support. In other words, what kind of rotten compiler are still used on multi-million-dollar machines?
I think it is out of question to support gcc 4.3 to 4.6. GCC 4.3.6 was released June 27, 2011. GCC 4.2.4 is three years older, from May 19, 2008. Does anyone (has to) use it or even older versions? I'll test the upcoming release candidates with GCC 4.7 and propose to officially support it.
What about ICC? Is someone using or at least testing it?
Should we add experimental Clang support?
What about exotic compilers from Jugene and other super computers? We should mention them when someone got Dune working with them.
Olaf Ippisch (olaf.ippisch@iwr.uni-heidelberg.de) commented on the issue:
We once agreed on a developer meeting to support compilers for at least five years. This would include gcc 4.1.2 which was released in 2007 (and is the most modern compiler on JUGENE).
-
Bård Skaflestad (bard.skaflestad@sintef.no) commented on the issue:
For information only,
Some of our customers have mature cluster systems for which GCC 4.1.2 is the most recent compiler (and especially run-time support library) package provided by the system vendor. I won't exclude the possibility of convincing these customers to upgrade their compiler, but in all likelyhood such a process will require recertification of the clusters. In other words: more than a year's effort.
If Dune chooses to require, say, GCC 4.4+, we will have no choice by to base our solution on older and gradually unsupported releases of Dune.
-
Bård Skaflestad (bard.skaflestad@sintef.no) commented on the issue:
For information only,
Some of our customers have mature cluster systems for which GCC 4.1.2 is the most recent compiler (and especially run-time support library) package provided by the system vendor. I won't exclude the possibility of convincing these customers to upgrade their compiler, but in all likelyhood such a process will require recertification of the clusters. In other words: more than a year's effort.
If Dune chooses to require, say, GCC 4.4+, we will have no choice by to base our solution on older and gradually unsupported releases of Dune.
Finally, I have some supporters when it comes to supporting old compilers. Thanks Bard.
Besides suppporting many compiler is a good thing. There were various occasions where standard compliancy could only achieved through various compiler (versions). Some older gcc versions seem to be more strict in some regards (e.g. template keyword).
IMHO gcc-3.4 could be dropped. (Still it would be interesting whether DUNE still compiles with it.)
ICC: On the helics cluster there is version 12.0.5 installed. What about BWGrid?
-
Bård Skaflestad (bard.skaflestad@sintef.no) commented on the issue:
@Markus: You're welcome. I've come to cherish backwards compatiblity a lot in recent years and the fact that Dune will Just Work[tm] on these systems speaks volumes.
Sorry about the double post earlier, by the way. I 'fat fingered' the FlySpray buffer.
-
Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:
My personal stance on that matter is that supporting old compilers is well and nice, but as soon as this support hampers productivity it should be dropped. IMHO GCC 4.1 (as well as probably 4.2 and 4.3) is such a case. IMO users stuck with half a decade-old operating systems should simply build a newer version of a compiler on in their home directory or scratch space. (that's not too difficult: http://gcc.gnu.org/install/build.html)
besides, newer compilers usually provide a quite reasonable speedup: When I switched from GCC 4.2 to 4.3 quite some time ago, I immediately got 20% more performance and I heard rumors that using GCC 4.6 instead of GCC 4.5 speed things up by 10% for PDELab.
I acknowledge, though, that opinions on that subject are quite diverse...
Using other compilers then the pre-installed one may be prohibited by policy. I think on JUGENE the policy was that user had to use xlc, and using gcc was only allowed once it could be shown that Dune wouldn't build due to compiler bugs and IBM was refusing to fix xlc.
And even if it is possible to build a newer compiler it may be impossible to build a MPI matching both that compiler and the machine you're running on, because MPI will probably require special proprietary drivers.
-
I propose to change the page to following. Actually I have no clue which version of automake, autoconf, and libtool we support, but I think we should not claim to support automake 1.5 which was released probably around 2001.
- a standard compliant C++ compiler [tested are g++ (>= 4.1), should work with recent version of icc and clang (>= 3.0)]
- automake (>= 1.9) // was 1.5
- libtool (>= 2.0) // was != 1.5.22 [OSX/fink]
-
I changed the page and request autoconf (>= 2.62) and libtool(>= 2.2). That are versions released in 2008 and not longer the ones from 2001.
A node on old versions in general and g++ 4.1 in particular: I wanted to test Dune on Debian Etch (4.0) but could not find a simple download. Testing becomes really difficult that way.
-
Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) commented on the issue:
I just noticed that the FAQ need the same kind of love:
