ropp_tools compilation on Linux 64 bit machine

[frae]

compilation fails with the following error:

efc -Vaxlib -fp_port  -I../build -O3 -size_lp64 -i8 -Vaxlib -I/data/nwp/sa/grassaf/ropp//ropp/efc//include -c -o tokens.o `test -f '../strings/tokens.f90' || echo './'`../strings/tokens.f90
efc: Command line warning: ignoring option '-fp'; no argument required
   external function TOKENS_STR
   external function TOKENS_INT
   external function TOKENS_SNGL
     call sp_getnum(tokenlist(i), arr(i), iflg)
          ^
Error 260 at (197:../strings/tokens.f90) : This subroutine has the wrong number of arguments or arguments with the wrong name, type or rank
   external function TOKENS_DBLE
     call sp_getnum(tokenlist(i), arr(i), iflg)
          ^
Error 260 at (239:../strings/tokens.f90) : This subroutine has the wrong number of arguments or arguments with the wrong name, type or rank

2 Errors
compilation aborted for ../strings/tokens.f90 (code 1)
make[1]: *** [tokens.o] Error 1
make[1]: Leaving directory `/home/nwp/sa/frae/temp/ropp_tools/build'
make: *** [all-recursive] Error 1

I assume this is the usual problem with integer 8 byte on the 64 bit machine but I was unable to find a fix in the flib files.

[Dave Offiler]

Root cause tracked to deficiencies in flib - see Ticket #74.

Investigated efc compiler switches, and the -i8 switch appears to set both integer and reals to 8-byte defaults. Changing -i8 to -i4 (I think the default, but that could change) in the configure_efc_linux script cures the problem as reported in this Ticket, and all of ropp_tools now compiles without any errors (but still many warnings). Whether 3rd party libraries such as netCDF etc also need re-compiling with the same setting is yet to be tested...

As part of this investigation, the problem was also cured by commenting out the 'use flib' statements in the 2 offending real routines in tokens.f90 and including an explicit interface to the appropriate flib sp_getnum routine (taken from the STRPAK module)

Not tried, but an obvious alternative solution would have been to replace the called flib routine with a local one doing the same (trivial) function. This would be a better long-term solution as true 64-bit compilation would then work (at least in this particular case). See also Ticket #40

There are other isses with configure_efc_linux (not related to this Ticket) which are being tested, so the configure file with the -i8 --> -i4 change is not yet committed