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

[Alan W. Irwin]

On 2012-10-19 02:18-0700 Alan W. Irwin wrote:

> 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.

Let me marshall the arguments further concerning this hypothesis now that
I have had some sleep.

The issue appears for the Windows binary versions of CMake-2.8.5,
2.8.8, and 2.8.9, and I think (but cannot recall clearly) that it also
occurred at least once for the bootstrapped build of CMake-2.8.9. Of
course, there could be a long-term memory-management issue for the
code that generates the Fortran link command for the "MSYS Makefiles"
generator that affects all recent CMake versions.  Later today I will
be able to say more about that when I try another bootstrapped build
based on my present (4.5.2) MinGW version.  But regardless of whether
bootstrapped builds are more reliable in this respect, the symptoms of
memory management issues are often intermittent and depend on all
sorts of implementation details so I expect the symptoms for the
bootstrapped version could be different than the Windows binary
version which was presumably built with a Windows compiler rather than
MinGW compiler and also different between MinGW versions.

The issue occurred first not only for the full te-gen build system,
but also for a completely simplified version of it.  For what it is
worth those simplifications were implemented by removing all sorts of
te_gen build-system CMake code with constructs like

if(whatever)
.... (many CMake commands)
endif(whatever)

where whatever was not defined.  I don't know the CMake internal
implications of code that is removed this way, but I doubt the result
is identical to actually removing the code from the file since I got
the bad link command issued for the exact te_gen equivalent (only the
names were changed) of my simple test case, but never for that simple
test case.

The issue is always specific to the generation of the Fortran link
command for the "MSYS Makefiles" generator.  If it is some wine-1.5.15
problem why does the intermittent problem always occur just for that
limited case?  Remember, for the same platform I did a bootstrap build
of CMake with no obvious issues, and I did very extensive testing of C
results (with complete linking commands always issued for the C
libraries involved) for ephcom2 with no obvious issues.  Also, when
the Fortran link command generated by CMake was working, I did a
modest (less than 1-minute of cpu time) but successful test of the
Fortran run-time with the ephcomf Fortran library.  In contrast, there
_are_ run-time issues for MinGW gfortran-4.6.2 revealed by the
extensive Fortran run-time testing (up to one hour cpu time when it is
working) I get with the te_gen package.  But I doubt the generation of
the Fortran library link command by CMake itself depends in the
slightest on Fortran run-time issues so long as a platform is capable
of building a simple Fortran test application that can be successfully
run (which is the case for all variants I have tried so far).

I suspect that no current test platforms for the "MSYS Makefiles" case
include a check that the Fortran link command for libraries actually
generates both a *.dll and *.dll.a form of the library.  Would it be
straightforward to arrange such a test?  Perhaps I just haven't run my
simple test case (for a "Hello World" Fortran library) often enough to
find a case where it didn't generate the *.dll.a form of the library
Thus, routine simple testing for this potential issue might turn up
some (intermittent) instances where it occurs.

>
> 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.

So far this morning there have been no takers, but I hope that changes
since I am really stumped by CMake _intermittently_ not issuing the
correct link command for libraries with no consistent pattern I can
spot with regard to anything I change.

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
__________________________