EC BUFR build problems

[Ian Culverwell]

The ROPP6.0 beta reviewer reported problems building the ROPP BUFR library with CYGWIN gfortran.

Note that the ROPP6.0 Release Notes list “the ECMWF BUFR library may not fully build on Cygwin with the default gcc” as a known problem with ROPP. Note further that build support for the ECMWF BUFR is not as complete and portable as for the MetDB package.

We'll do what we can.

[Ian Culverwell]

Note there were also problems building EC BUFR 000387 on pgf95 vn 11.7 at RHEL6/linux. After consulting ECMWF guys, the following solution was found: change

CFLAGS  = -O2  -Dlinux -DLITTLE_ENDIAN  $(MEM_MAP)

to

CFLAGS  = -O2  -Dlinux -DLITTLE_ENDIAN  $(MEM_MAP) -DPOINTER_64 -DINTEGER_IS_INT

in ecbufr_configure_pgf95_linux.

Builds,and can be built on, OK. Incorporate in ROPP7.0.

Leave ticket open as the Cygwin issues still haven't been resolved.

[Dave Offiler]

Postponing to v7.1

[Dave Offiler]

Cygwin ECMWF BUFR library build problem still exists with latest gcc v4.7.3.

The problem occurs when the EC BUFR build/test system attempts to compile PBGroutines.c; generating an error 'unknown type name __offset64_t'. This symbol does not appear in any ECBUFR or gcc header file as a #define or similar. It most likely should be defined in a gcc/system header file - for instance, on RHEL6 in /usr/include/stdio.h:

  typedef __off64_t off64_t;

and in /usr/include/unistd.h:

  extern __off64_t lseek64 (int __fd, __off64_t __offset, int __whence)

etc.

In turn, the routines defined in the C-code are not included in the libbufr.a object library and downstream test programs fail to link with missing references. Despite this, the EC system does install the (incomplete) library to the target directory <PREFIX>/lib, but applications will fail to link if they use (say) pbopen().

Since ECMWF do not support Cygwin as a platform for their code, and the ROM SAF is not responsible for the ECMWF package - though the fault appears to lie in the gcc headers - this may have to be left as a "won't fix". The solution is to use the Met Office BUFR library, except if the EUMETSAT netCDF-4 to (EC) BUFR tool is required on Cygwin (unlikely?).

[Dave Offiler]

Cygwin ECMWF BUFR library build problem still exists with latest gcc (v4.8.2) on Cycgwin dll v1.7.29:

$ gcc --version
gcc (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Extract from build_deps.log:

gcc -O2 -w -Dlinux -DLITTLE_ENDIAN -DINTEGER_IS_INT -c PBGroutines.c
PBGroutines.c:17:1: error: unknown type name "__off64_t"
 typedef __off64_t off64_t;
 ^
../options/options_cygwin:7: recipe for target 'PBGroutines.o' failed
make: *** [PBGroutines.o] Error 1

This error terminates the 'make'.

Note that the problem symbol __off64_t has two leading underscores; in our Cygwin header, there is only one:

$ cat /usr/include/unistd.h
#ifndef _UNISTD_H_
#define _UNISTD_H_

# include <sys/unistd.h>

#endif /* _UNISTD_H_ */

$ grep off64 /usr/include/sys/unistd.h
_off64_t _EXFUN(_lseek64, (int __filedes, _off64_t __offset, int __whence ));

which looks to be the same definition (with somewhat different syntax) as in the RHEL6 equivalent header shown above.

As an experiment, the next stage might try editing the symbol in PBGroutines.c back from 2 to 1 underscore and attempt to build again.

[Dave Offiler]

Problem still occuring with Cygwin 1.7.30 with gcc v4.8.2.

However, the solution turns out to be simpler than hacking the EC code; a simple

 gcc -c PBGroutines.c

works whereas the full command run by Makefile:

gcc -O2 -w -Dlinux -DLITTLE_ENDIAN -DINTEGER_IS_INT -c PBGroutines.c

fails as above; it didn't take long to find that -Dlinux was the culprit. This switch comes via FFLAGS which is set in ecbufr_configure_gfortran_cygwin (and ecbufr_configure_g95_linux); the soluton is merely to remove this switch from the mini-scripts allowing the gfortran build to complete and to successfully runs the make test under buildpack. Goes to show that Cygwin isn't Linux...

Note that the ECBUFR build with g95 still has linker problems when building the test programs, but that's for another ticket (see also #340 for why this might be a won't fix).

When the two Cygwin mini-scripts are modified in the ROPP-8 prototype branch, this ticket can be closed.

PS: our ROPP ./configure script in the ROPP-7.0 tarball which I used for this ticket is out of date and doesn't recognize the 64-bit Cygwin as such, so the ECBUFR has not been tested against ROPP_IO tools. A re-generated script using a newer autotools setup might fare better...

[Dave Offiler]

Correction to above: strictly, the culprit is CFLAGS not FFLAGS, but ECBUFR still builds OK if both occurrences of -Dlinux are removed, and this seems to be a consistent and logical thing to do.

Modified both mini-scripts in branch ROPP80_prototype (as [4234]) and closing as fixing this particular ticket.