diana:windows:building:issues

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
diana:windows:building:issues [2009-11-12 18:30:58]
dages 		diana:windows:building:issues [2022-05-31 09:29:31] (current)
Line 1: Line 1:
 ====== Unresolved issues ====== ====== Unresolved issues ======
 +
 +**OUT OF DATE** most of these issues have been resolved or worked around, or were only relevant in the initial, experimental phase.
 +
 +===== --prefix =====
 +
 +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.***
 +
 +===== Shared 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
 +
 +  - place ''LDFLAGS=-no-undefined'' in your environment before running ''configure'', and
 +  - manually load all the required libraries when you aren't using libtool
 +
 +===== Compiler crash =====
 +
 +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.
 +
 +===== Fortran preprocessing =====
 +
 +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
  
 ===== LDFLAGS ===== ===== LDFLAGS =====
Line 9: Line 70:
  
 ===== Fortran ===== ===== Fortran =====
 +
 +**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   /bin/sh ../libtool --tag=F77   --mode=compile gfortran  -g -O2 -x f77-cpp-input -c -o getvar.lo getvar.f
  • diana/windows/building/issues.1258050658.txt.gz
  • Last modified: 2022-05-31 09:23:14
  • (external edit)