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

Alan W. Irwin irwin at beluga.phys.uvic.ca
Thu Oct 25 21:15:40 EDT 2012


On 2012-10-25 19:43-0400 David Cole wrote:

> We're using the same compiler that we used in September 2011.

For future reference what is that compiler?

I was just about to write the list with the same conclusion since
downloaded 2.8.5 (with *.zip file timestamped on Jul  8  2011) also
shows the issue.

>
> It's a new feature that's been added since then which uses
> file(STRINGS as the compiler identification mechanism.


OK.  I don't think file(STRINGS ... is used in the ephcom build system
so that explains why I got good results before for the September 2011
test with downloaded CMake which also didn't use file(STRINGS to determine the
compiler identification.

> Maybe you should take this to the Wine people now. Pretty sure at this
> point that it's a problem in their implementation of some API that we
> call from file(STRINGS.

I think you are probably right.  It appears it was just by chance (no
use of file(STRINGS ... ) that I avoided this wine issue last year, and
obviously we want that functionality to work (as it does now for the
bootstrapped version ) for the downloaded CMake version.

@ Clint:
What do you think?  Can you confirm on the Wine platform that
Bill's simple test case for file(STRINGS ... using the executable file created by

gfortran $CMAKE_INSTALL_PREFIX/share/cmake-2.8/Modules/CMakeFortranCompilerABI.F

does not work reliably on Wine for downloaded
CMake but does work reliably for bootstrapped CMake?

@Bill or Brad:

I confirm the bad empty result for downloaded CMake for 
Bill's test, but the result I get here for that test of the
bootstrapped version yields a string

-- [INFO:sizeof_dptr[4]ABI Detection]

that is different than what Bill said.  Is that difference significant?

@ Clint: do you feel Bill's test is a simple enough test to motivate the Wine
developers to fix the issue or would it be better to narrow it down
even further?

One possibility I have suggested for that (since CMake
has a hell of a lot of source code) is to vastly simplify the source code for
the executable that is doing the file string searching down to the
simplest possible code that shows the effect.

Another possibility for simplifying the test is to use the grep and
sed commands to tease out just the surrounding few bytes if necessary
from the searched for strings to find the smallest bit patterns
(hopefully just ascii) that yield a null result for the file string
search for downloaded CMake but the correct result for the
bootstrapped version I am working on that simplification of the file
that is being searched at the moment, but I think the source code
simplification for the executable that does the file searching might
also be quite useful when presenting the case to the Wine developers.

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
__________________________



More information about the cmake-developers mailing list