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:59:47]
dages 		diana:windows:building:issues [2022-05-31 09:29:31] (current)
Line 1: Line 1:
 ====== Unresolved issues ====== ====== Unresolved issues ======
  
-===== LDFLAGS =====+**OUT OF DATE** most of these issues have been resolved or worked around, or were only relevant in the initial, experimental phase.
  
-In order to generate DLLs, libtool needs ''LDFLAGS=-no-undefined''.  We need to+===== --prefix =====
  
-  - understand //why// +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//
-  - figure out where to handle it+
  
-===== Incorrect library names =====+**XXX is this really an issue?  perhaps we should just build static libraries.***
  
-Now that's strange:+===== Shared libraries =====
  
-  libtool: link: g++ -o .libs/dsets.exe dsets.o h5cpputil.o  ../../test/.libs/libh5test.a ../../c++/src/.libs/libhdf5_cpp.a /mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a ../../src/.libs/libhdf5.a -lws2_32 -L/mingw/lib/gcc/mingw32/4.4.0 +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
-  g++.exe: C:/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory+
  
-This is a well-known issue, see for instance http://old.nabble.com/forum/Search.jtp?query=mingw+%22dll.a%22.  Executive summary: the ''.la'' files contain incorrect information.+  - place ''LDFLAGS=-no-undefined'' in your environment before running ''configure'', and 
 +  - manually load all the required libraries when you aren't using libtool
  
-The simplest fix is to clear ''library_names'' in all ''.la'' files:+===== Compiler crash =====
  
-  $ find /mingw/lib -name '*.la' | while read f ; do echo $f ; sed -e "s/library_names='[^']*'/library_names=\'\'/" $f > $f- && mv $f- $f ; done+Oops:
  
-The problem is that the same will happen to your own shared libraries, unless you fix libtool.  You need to edit ''/mingw/share/aclocal/libtool.m4'', ''/mingw/share/libtool/libltdl/configure'', ''/mingw/share/libtool/config/ltmain.sh'' and ''/mingw/bin/libtool''; replace any occurrence of ''%%library_names_spec='$libname.dll.a'%%'' with ''%%library_names_spec=''%%'', and any occurrence of ''*.dll.a)'' with ''*.a''.+  $ 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 ===== 
 + 
 +In order to generate DLLs, libtool needs ''LDFLAGS=-no-undefined''.  We need to 
 + 
 +  - understand //why// 
 +  - figure out where to handle it
  
 ===== 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.1258052387.txt.gz
  • Last modified: 2022-05-31 09:23:14
  • (external edit)