| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
diana:windows:building:issues [2009-11-16 11:12:30]
dages |
diana:windows:building:issues [2022-05-31 09:29:31] (current)
|
| ====== 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.*** |
| |
| **THIS SECTION IS INCORRECT** | ===== Shared libraries ===== |
| |
| Now that's strange: | 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 |
| |
| 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 | - place ''LDFLAGS=-no-undefined'' in your environment before running ''configure'', and |
| g++.exe: C:/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory | - manually load all the required libraries when you aren't using libtool |
| |
| 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. | ===== Compiler crash ===== |
| |
| The simplest fix is to clear ''library_names'' in all ''.la'' files: | Oops: |
| |
| $ find /mingw/lib -name '*.la' | while read f ; do echo $f ; sed -e "s/library_names='[^']*'/library_names=\'\'/" $f > $f- && mv $f- $f ; done | $ 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. |
| |
| 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''. | 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 |