Hi,
I occasionally build with gnu 4.1.2 on an old cluster.
The main reason to continue support is that 4.1.2 is the default
on old red hat platforms, but we shouldn't put much effort into
that support. I second Dan's call to deprecate 4.1.2 rather than make
it obsolete (i volunteer to out procrastinate Dan ;-).
Much of the build did work recently; the last time i built with it on
Mon Mar 2 23:17:59 EST 2015
# Amber configuration file, created with: ./configure -nofftw3 gnu
i fixed at least 1 compilation failure; the main issues left were, eg,
In file prmtop_type.F90:40
character, allocatable, dimension(:) :: atom_name
1
Error: Attribute at (1) is not allowed in a TYPE definition
as well as some python related issues that i did not investigate
but felt might be due to the 2.4 python version on this old cluster
or due to an unpristine repo:
IOError: [Errno 2] No such file or directory: 'chemistry/amber/openmmreporters.py'
byte-compiling /nfs/10/srb/amber/amber/lib/python2.4/site-packages/pymsmtmol/readpdb.py to readpdb.pyc
SyntaxError: ('future feature absolute_import is not defined',)
scott
On Tue, Mar 10, 2015 at 09:09:55PM -0600, Daniel Roe wrote:
> I have no problem with dropping support. However, maybe for this
> release (or future releases) we add a flag that just disables the
> build of the affected components, so that systems still rocking the
> old school compilers have a relatively simple option for getting the
> majority of Amber working. I will volunteer to implement this if it
> ends up being the consensus. If we just want to drop 4.1.2 support
> entirely I have no strong objections.
>
>
> On Tue, Mar 10, 2015 at 8:53 PM, Jason Swails <jason.swails.gmail.com> wrote:
> >
> > Due to my recent work/attempts to get Amber working with GCC 4.1.2 again, I wanted to raise the question of whether or not we should drop support for this particular compiler altogether. I???m personally in favor of dropping support for the following reasons:
> >
> > - It is a limiting compiler; 3D-RISM, mdgx, part of the sander API, and the PBSA FFT solver do not work because fftw-3 uses features not supported by that version of GCC.
> > - GCC 4.1.2 was released over 8 years ago, and only RHEL 5 (superseded by RHEL 6/7, released in 2007, and nearing end-of-life) is still in use (?) and ships with this version of GCC; even it has GCC 4.4 in its yum repositories.
> > - No developers use GCC 4.1.2 regularly (or they would have found the build failing for the past 5 months)
> > - Maintaining GCC 4.1.2 compatibility will only get harder, and the hacks thrown in to cut out the pieces that don???t work with it make the code more complex
> >
> > In my opinion, the biggest strike against supporting GCC 4.1.2 is that since no developer uses it, features and code that break compatibility likely won???t be found until months after the code was introduced, and nobody really knows which features are supported and which ones aren???t.
> >
> > At some point compatibility will simply have to be dropped. Should it be now, when the code will be a bit easier to simplify? Or do we wait until the workarounds become too hard? (And perhaps most importantly -- does anybody still rely on this for their work?)
> >
> > Thoughts?
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 11 2015 - 00:00:02 PDT
