Re: EPICS Base 3.14.12.2-rc1 available for testing

[Dirk Zimoch <dirk.zimoch@psi.ch>]

> I am going to guess that moving the "#include <ctime>" to be first in the
> stack as follows might take care of this, and that this might be less of a
> mess (messes accumulate) compared to interspersing the import from namespace
> std into the middle of the #include list which might cause issues on other
> compilers.
>
> #include <ctime>
> #include <cstddef>
> #include <cstdio>
> #include <cmath>
> #include <climits>
> #include <cstring>
>
> We have, it seems, one of everything old here including an old Solaris
> machine so I was trying to reproduce the issue here. The old perl upgrade
> install on our old solaris is finally done. Now the EPICS R3.14 latest build
> is failing I suspect because gnu make 3.79.1 is installed. Hopefully will
> get this reproduced soon on Monday. However, if you can try the above idea
> first it might be easier and faster.

The order of the include statements has no effect. What I did to solve 
the problem is to move the namespace import in front of all imports:

using namespace std;

#include <cstddef>
#include <cstdio>
#include <ctime>
#include <cmath>
#include <climits>
#include <cstring>

#include "epicsTime.h"
#include "epicsThread.h"
#include "errlog.h"
#include "epicsUnitTest.h"
#include "testMain.h"

Dirk

PS: Yes, the perl and make upgrade is a pain. That is exactly why I did 
not like the requirement for the new versions. One could also demand to 
upgrade to a newer C++ compiler, but then maybe EPICS libraries would 
not work together with the installed programs (e.g. EPICS-TCL interface).