[gmx-developers] master branch does not compile

Erik Lindahl erik at kth.se
Wed Feb 9 17:16:45 CET 2011


On Feb 8, 2011, at 11:39 PM, Justin A. Lemkul wrote:
> Roland Schulz wrote:
>> On Sun, Feb 6, 2011 at 3:59 PM, David van der Spoel <spoel at xray.bmc.uu.se <mailto:spoel at xray.bmc.uu.se>> wrote:
>>    On 2011-02-06 21.50, Roland Schulz wrote:
>>        Hi,
>>        it compiles fine with gcc 4.3.x, 4.4.x and 4.5.x (assuming minor
>>        version
>>        behave the same).
>>        This seems to be a bug in 4.2 because this line is not
>>        calling OptionInfo(const gmx::OptionInfo&) but  OptionInfo(const
>>        AbstractOptionStorage &option). And the later is not private so
>>        it is OK.
>>        4.2 is not maintained anymore. Do we want to support 4.2
>>        nonetheless?
>>    Nja, on Apple it is less simple to update compilers than on Linux.
>>    I'll try it on my cluster later on.
>> DarwinPorts has gcc 4.4:
>> http://gcc44.darwinports.com/
> Some of us are still in the dark ages, and without getting into too much detail, suffice it to say that the only GCC I can have access to on our main cluster are versions 3.3 and 4.2.2, which suffer from the problem David reported.  I would hope that Gromacs would remain backwards compatible, but I realize that I might be asking too much.  We have some smaller clusters with newer GCC (>=4.3), but our main supercomputer is somewhat outdated and will not be updated.
> Just wanted to throw that fact out there.  I realize there are compelling reasons to make use of features accessible to newer compilers (and that most people will have access to them), but that's not always possible for some of us.

The problem isn't that we are abandoning old working compilers, but that it appears to be a bug in the compiler, not the code.

We still try very hard to make sure any released version works even on old compilers, and whenever possible we do our utmost to work around bugs, but the problem in this case is that it concerns the cutting edge development branch where we are focusing all current efforts on designing a more modular codebase in C++, and then it is simply not a very high priority to start chasing an error message that only appears to be a bug in a several year old compiler, which we might or might not be able to work around.

If somebody else finds a good solution we're happy to commit it, but right now I think it's better if we focus people's time on the new modular design work rather than trying to isolate bugs in old gcc versions!



Erik Lindahl <erik at kth.se>
Professor of Theoretical & Computational Biophysics
Department of Theoretical Physics & Swedish e-Science Research Center
Royal Institute of Technology, Stockholm, Sweden
Tel: +46855378029 Cell: +46703844534 

More information about the gromacs.org_gmx-developers mailing list