[cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform

[Alan W. Irwin]

I am getting some strange but apparently intermittent results for the
gfortran link command generated with the CMake "MSYS Makefiles"
generator for a MinGW/MSYS/Wine platform.  What happens is that
sometimes the library name has the lib prefix dropped and all the -Wl
options disappear in the link command so that the result is only
<target_name>.dll rather than lib<target_name>.dll with no
corresponding *.dll.a file being generated. In other words, I believe
these shared Fortran libraries are intermittently being incorrectly
linked as modules.

Here is the expected good result on this platform generated for a
really simple example (with target name libhello) which unfortunatly
worked all the times I tried it so I cannot use it for a verification
example.

Linking Fortran shared library liblibhello.dll
/Z/home/wine/newstart/bootstrap_cmake/cmake-2.8.9/bin/cmake.exe -E remove -f CMakeFiles/libhello.dir/objects.a
/z/home/wine/newstart/MinGW/bin/ar.exe cr CMakeFiles/libhello.dir/objects.a @CMakeFiles/libhello.dir/objects1.rsp
/z/home/wine/newstart/MinGW/bin/gfortran.exe     ../libhello.def -shared -o liblibhello.dll -Wl,--out-implib,liblibhello.dll.a -Wl,--major-image-version,1,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/libhello.dir/objects.a -Wl,--no-whole-archive 
Creating library file: liblibhello.dll.a
make[2]: Leaving directory `/z/home/wine/newstart/test_fortran/build_dir'
/Z/home/wine/newstart/bootstrap_cmake/cmake-2.8.9/bin/cmake.exe -E cmake_progress_report /Z/home/wine/newstart/test_fortran/build_dir/CMakeFiles  2 3
[ 66%] Built target libhello

Here is a bad result for a more complex project, te_gen.

Linking Fortran shared library ../dll/xxxx.dll
cd /Z/home/wine/newstart/te_gen/build_dir/src && /z/home/wine/newstart/MinGW/bin/gfortran.exe      -shared  -o ../dll/xxxx.dll "CMakeFiles/xxxx.dir/chebfit.f.obj" 
make[3]: Leaving directory `/z/home/wine/newstart/te_gen/build_dir'
/Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe -E cmake_progress_report /Z/home/wine/newstart/te_gen/build_dir/CMakeFiles  1
[100%] Built target xxxx

Note, the target name was xxxx, and there is no lib prefix on the
library name and all the essential -Wl options are dropped.  So I
think what is going on is this library is being linked as if
it were a simple module rather than a library.

This was for a hacked variant of te_gen where large swathes of the
build system had been dropped to remove most of its complexity.  The
above example isn't exactly equivalent to the simple project (I still
had some logic in there establishing a dll location), but eventually I
removed that as well so it was exactly equivalent to the simple
project, and the resulting link command was _still_ incomplete.

I then made some trivial change (I think I rearranged one of the
continuation lines on my bash script running these test builds), and
all of a sudden hacked te_gen had a complete link command.  I then
restored te_gen to its full complexity and it _still_ had a complete
link command.  It's also possible the previous incomplete link
command was just for the downloaded Windows binary version of CMake-2.8.9,
but IIRC, I got bad results for both the binary version and the
bootstrapped version.  Anyhow, the good linking results occurred for
the bootstrapped build version of CMake-2.8.9, and I was so happy to
see those good results after fiddling with this for days, that I
didn't try the experiment of using the binary version of CMake-2.8.9
with absolutely nothing else changed.

Note that MSYS/MinGW/Wine had worked fine for a different project
(ephcom2) that is made up of several C libraries (with many different
C executables to run-time test those C libraries) and one Fortran
library with one executable to run-time test that Fortran library. The
Fortran library always was linked with a complete command (through
many builds) and the Fortran executable worked at run-time with no
issues.  In contrast, te-gen has just one Fortran library that is
linked to the ephcom2 Fortran library (which in turn is linked to the
ephcom2 C libraries). The te_gen Fortran library has many Fortran
executables to test that library at run time.  Unfortunately, it
turned out those executables showed lots of run-time errors.

Those bad run-time results for te-gen were all for the MinGW version
of gcc/gfortran-4.6.2.  So as an experiment I downgraded to MinGW
gcc/gfortran-4.5.2.  All of a sudden for that combination of compilers
(with no changes to the build systems, but some minor changes to the
bash scripts that controlled the build), the one Fortran library for
ephcom which had always had a complete link command generated by CMake
before for gfortran-4.6.2, had a generated link command that was
incomplete for gfortran-4.5.2! This bad result was for the downloaded
Windows binary version of CMake-2.8.9. I also tried 2.8.8 and 2.8.5
with the same bad linking result.

Tomorrow I am going to try a bootstrapped version of CMake-2.8.9 built
with g++-4.5.2 to see if that will make any difference. (The
bootstrapped version of CMake-2.8.9 that I have now only works with
version 4.6.2 of the compilers, i.e, the compiler version it was
built with.)

So this has been a long, sad, and continuing saga where I still
haven't pinned down exactly why on some occasions CMake generates
incomplete link commands for Fortran libraries.

However, my feeling at this stage is the complete or incomplete
Fortran link commands are not caused by anything I am doing, but are
instead caused by some memory management issue for CMake that
sometimes clobbers the variables that control whether the linking is
for a module or library.

To test that hypothesis further, I am willing to run a gdb session
(gdb.exe is available as one of the MinGW executables) on CMake while
it is executing to help see what is going on, but I would need some
help from experts here with navigating my way throught the many
different CMake routines and to find exactly what variables affect the
module versus library style of Fortran linking.

Although it is hard for me to imagine some Wine-1.5.15 bug
intermittently affecting whether CMake generates a full or incomplete
link command for Fortran libraries, I guess that is a possible
explanation of what I am seeing as well.  So that raises the important
question of what is the status of "MSYS Makefiles" testing on
proprietary Windows platforms? I know from what Bill has said recently
that "MSYS Makefiles" builds are tested regularly on a couple of
machines, but do those tests include Fortran? And if so, what version
of the MinGW gfortran compiler is being tested, and does that testing
include attempts to link Fortran executables with Fortran libraries?
(Note the incomplete linking is normally detected by such attempts.
Alternatively you could test whether both *.dll and *.dll.a files are
being produced by the link step.) Does anyhow here have lots of
MinGW/MSYS Windows experience with gfortran so they are in a position
to comment on the reliability of the link commands for Fortran
libraries generated by cmake -G "MSYS Makefiles" for that platform?

This generated Fortran link command issue has already given me several
miserable days so any help you could give me with this issue would be
much appreciated.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________