Unresolved issues

OUT OF DATE most of these issues have been resolved or worked around, or were only relevant in the initial, experimental phase.

You'll notice that I recommend installing several components (HDF, NetCDF, Grib…) in their own directories under /opt. The reason for this is that it makes it easier to clean up spills while working out the build process. The downside is that although everything will build correctly, some components may fail to run

XXX is this really an issue? perhaps we should just build static libraries.*

Windows doesn't have transitive shared library dependencies. What this means, in plain language, is that you can't assume—as you can on ELF systems—that loading a shared library automatically loads all of its dependencies. Therefore, libtool will refuse to generate shared libraries unless you promise that whenever you load it, you will also load all of its dependencies. To do that, you must

1. place LDFLAGS=-no-undefined in your environment before running configure, and
2. manually load all the required libraries when you aren't using libtool

Oops:

$ gcc -o hello hello.c
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This rather cryptic message means that “this application” (i.e. gcc) threw an unhandled exception (i.e. an uncaught signal). There can be a million reasons for this, but odds are the problem is simply that gcc failed to create a temporary file. You can confirm this by adding -pipe to the gcc command line; if it works with -pipe but not without, the problem is related to temporary files.

Check your $TMP, $TEMP and $TMPDIR variables. At least one of them must be set and point to an existing directory to which you have write access.

Add the following three lines to your ~/.profile:

export TMPDIR=/tmp
export TEMP=/tmp
export TMP=/tmp

and paste them into all your open terminals so they will take effect immediately.

There is a looong thread about this issue at http://old.nabble.com/Failed-Install-under-XP-td17636207.html.

You may come across something like this:

$ make termchar.o
g77  -g -O2 -pipe -DG77 -c -o termchar.o termchar.f
termchar.f: In subroutine `termchar':
In file included from termchar.f:0:
termchar.f:41: error: undefined or invalid # directive
termchar.f:44: error: undefined or invalid # directive
termchar.f:47: error: undefined or invalid # directive
make: *** [termchar.o] Error 1

It means g77 does not pass termchar.f through the preprocessor. You have to rename the file to termchar.F, which can be tricky in MSYS:

$ touch foo.f
$ mv foo.f foo.F
mv: `foo.f' and `foo.F' are the same file

You can work around this by renaming the file in two stages:

$ mv foo.f foo.f-
$ mv foo.f- foo.F

In order to generate DLLs, libtool needs LDFLAGS=-no-undefined. We need to

1. understand why
2. figure out where to handle it

not an issue with 3.4.5

/bin/sh ../libtool --tag=F77   --mode=compile gfortran  -g -O2 -x f77-cpp-input -c -o getvar.lo getvar.f
libtool: compile:  gfortran -g -O2 -x f77-cpp-input -c getvar.f  -DDLL_EXPORT -o .libs/getvar.o getvar.f:93.65:

      data cend/ ' ' , '.' , '/' , '$' , '#' , '?' , ',' , ';' , '\\' / 
                                                                 1
Warning: initialization string truncated to match variable at (1)
libtool: compile:  gfortran -g -O2 -x f77-cpp-input -c getvar.f -o getvar.o >/dev/null 2>&1

This does not happen on Ubuntu, but in all fairness, we're using a different compiler (or, to be exact a different compiler version: gfortran 4.2.4 on Ubuntu, gfortran 4.4.0 on Windows).