[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 13:08-0400 David Cole wrote:

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

Thanks for that offer, and yes I do have the complete builds scripted
by bash (see comment below) for both te_gen and ephcom.  te_gen is a
complicated test case because it depends on ephcom.  But fortunately I
currently have the generated Fortran link command issue showing up for
ephcom which considerably simplifies what I need to send you.

So let me simplify the ephcom build script as much as possible for you (while
it still demonstrates the bad symptoms for me), and I hope to get
back to you off-list ASAP with a complete example.

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

Are any of those 5 separate tests sensitive to an incomplete linking
statement being issued for Fortran libraries?  That won't generate any
errors until an attempt is made to link a Fortran application with
that badly linked library.  If the answer is these tests are sensitive
to the issue, then I will try (later today after I have sent you the
ephcom script) the 4.5.0 version of MinGW myself to be as consistent
as possible with these tests.  Of course, my experience is that simple
tests for this issue don't show anything, but my simple tests were not
extensive so if the above actually do a lot of such simple tests
relevant to this issue, that would be useful to know.

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

Clean rebuilds are not the issue since my bash scripts for running
each of these test cases always include a command to remove the build
tree before doing any test in a separate initially empty build tree.
I didn't use a script for the simple example, but in that case
as well I was alway careful to make a clean start with
an initially empty build tree.

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

Yes, and I will try to get back to you ASAP with that.

Thanks, again, for that offer!

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
__________________________