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

David Cole david.cole at kitware.com
Fri Oct 19 13:08:19 EDT 2012


Hi Alan,

Can you write a script that would reproduce the problem for us here if
we ran the script? (Even if the project that it has to build is
complex...)

There is nightly testing using MSYS Makefiles with GNU 4.5.0 with Fortran:

  http://open.cdash.org/buildSummary.php?buildid=2618838

and all the Fortran tests pass:

  http://open.cdash.org/viewTest.php?buildid=2618838&filtercount=1&showfilters=1&field1=testname/string&compare1=63&value1=Fortran

>From the way you describe things here, it sounds like you're switching
back and forth between versions of CMake, versions of gfortran, and
also modifying CMake code to narrow down and come up with a simple
case, and other actions ... all of which may have some interactions
with cached variable values. I don't think there's a memory clobbering
issue going on here (but there could be, I suppose), but rather more
likely some setting that gets stuck in the CMakeCache file but is then
not applicable after you make a code change in CMake, but the value is
still there in the cache, and maybe unexpectedly influences what is
generated. (This is all just suspicion and speculation, but reasonable
I think.) You especially should always do a fully clean re-build if
you change compilers, even if it's "just one" version number.

If it works for the simple case, but not for the complex one, then
some difference between those projects is the thing that triggers the
problem. It would be good using fully clean re-builds to give exact
steps to reproduce the problem in the simplest case. Although
reproducing it with a more complex case might certainly be more useful
than spending tons and tons of time trying to simplify it.

Again:
Can you write a script that would reproduce the problem for us here if
we ran the script? (Even if the project that it has to build is
complex...)


Cheers,
David


On Fri, Oct 19, 2012 at 5:18 AM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> 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
> __________________________
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



More information about the cmake-developers mailing list