Unfortunately that has not worked either. Others are also getting the same error so for now it's suggested to use the rc2 compiler. Will keep you updated when a solution is found!
I just tried this on two slightly different builds of 2.0, and was unable to reproduce the issue.
Are all users experiencing the issue using the same build ? Juan recently sent me an e-mail about this issue, but I suspect you may be using the same "centralized" build, and in this case, I would suspect an install or Python issue. in this case, if you could send the cs_config.py file found in the "<install_prefix>/lib/python<version>/site-packages/ncs" directory fo both version 2.0-rc2 and 2.0.1, I could compare the 2 and hopefully have something to suggest based on that info.
Most users at the university use v1.4 so I'm unsure who's experiencing the problem but there's a few who've all installed their own: I installed manually to my own machine and I think Juan used an install script. Here are the files you asked for - I cannot see any immediate difference between the two though.
Juan's modification seems to almost revert the behavior to the one we had before a change in revision 1661 (Oct 26 2010), which allowed us to avoid buffering the standard output.
With his patch, I assume Preprocessor log output is buffered when running "code_saturne check_mesh", though would be less of an inconvenience than not having the compile output.
Still, I did not reproduce this bug, so it may be related to a Python version. Which Python versions/Linux distributions did you encounter this issue on (on our side, I tested on versions of Python 2.4, 2.6, and 2.7.1 at least, though I would have to check the exact release versions).
check_mesh's output buffered in two parts although this isn't an issue (nor noticable except for large meshes).
The python is version 2.4 for my desktop (2.4.3 43.el5) (and I think on the cluster), linux distribution is Scientific Linux (Boron), 5.3 on the desktop and 5.2 on the cluster.