With gfortran 4.6 onwards, you run a real risk of invoking software-emulated 128-bit precision floating point operations when you thought you were asking for hardware-supported 64-bit operations. A symptom is that the linker requires -lquadmath to be added.
See this interesting article for more details:
libquadmath was introduced in GFortran 4.6 which fundamentally changed what the -fdefault-real-8 switch does. Rather than promoting all floating point arithmetic to double precision, it doubles the width of all floating point types, so explicitly typed double precision is converted to quad precision. This quad precision is orders of magnitude slower since it must be done in software, causing binaries built with -fdefault-real-8 to grind to a halt when built with GFortran 4.6 and newer.
The solution is to add -fdefault-double-8 to undo this implicit doubling of explicit real*8.
Guidance
When building ECMWF software which contains Fortran code, if you add -fdefault-real-8 then you should also add -fdefault-double-8 to the compiler flags. If the linker complains about missing quadmath symbols then you may need to rebuild the complete software stack - for example, you may encounter the problem when linking Metview, but the problem might have been generated when building emoslib. For CMake, this command-line option should work:
cmake ...... -DCMAKE_Fortran_FLAGS="-fdefault-real-8 -fdefault-double-8"