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

[David Cole]

On Thu, Oct 25, 2012 at 7:06 PM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2012-10-25 17:05-0400 Brad King wrote:
>
>> On 10/25/2012 04:51 PM, Alan W. Irwin wrote:
>>>
>>> bash.exe-3.1$
>>> /z/home/wine/newstart/bootstrap_cmake/install_4.7.0/bin/cmake.exe -P
>>> info.cmake
>>> -- [INFO:compiler[GNU]]
>>> -- [INFO:compiler_version[00000004.00000005.00000002]]
>>> -- [INFO:platform[MinGW]]
>>> -- [INFO:arch[]]
>>> bash.exe-3.1$ /z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe
>>> -P info.cmake
>>> -- [INFO:compiler[GNU]]
>>> -- [INFO:compiler_version[00000004.00000005.00000002]]
>>> -- [INFO:platform[MinGW]]
>>> -- [INFO:arch[]]
>>
>>
>> This shows that file(STRINGS) does work *sometimes* with the
>> pre-built binary.  You have a few ".exe" files for which it
>> does not work and a ".o" for which it does work.  The log
>> indicates it also failed for Fortran's ".o" file so it does
>> not depend just on ".exe" versus ".o".
>>
>> Since this all works on native Windows it is likely a problem
>> with the way Wine is running the MSVC-built binary and not with
>> CMake itself.  You have a work-around.
>
>
> It is true that I do have a workaround which appears to give excellent
> results in the many tests I have tried for a variety of MinGW/MSYS
> versions.  But those good results serve as motivation to figure out
> what the Wine problem is for the downloaded CMake so Wine will become
> a trustworthy platform in all respects for CMake.  Note also this
> issue has been introduced relatively recently.  I built ephcom (which
> includes a Fortran library) a year ago on Wine with a downloaded
> version of CMake with no issues.  That was a pretty extensive test
> leading up to the ephcom-2.0.2 release on 2011-09-14.
>
> What is the current compiler version used to build downloaded CMake
> versus the compiler version used in September 2011 for the same task
> when I successfully tested ephcom on Wine before? (The working
> hypothesis behind this question is it is that changed compiler version
> that is the source of the downloaded CMake trouble on Wine now.)
>
> To take a further step leading toward the goal of a Wine bug report
> that will help to solve this issue, I think we need a simpler test
> case which consists of a small C++ programme that copies only the
> relevant parts of the CMake code that are used to search files for
> strings.  (My knowledge of C++ and the CMake code base are not
> sufficient to dig out those relevant bits myself.) But assuming that
> test code was implemented in the same way that CMake searches for
> strings in files, it should also show good string searching results on
> the Wine platform for a version of that executable built with MinGW,
> but not with the compiler that is currently being used to generate the
> downloadable version of CMake.
>
> I don't expect the Kitware developers to carry this load further
> beyond answering the question above identifying what compiler is used
> now versus in September 2011 for the downloaded version. The Wine
> issue with (perhaps just one of) the Windows instructions generated by
> the current compiler is obviously and rightly not a first priority for
> them. However, if someone else with the required C++ and CMake
> internal code knowledge (Clint?) is willing to take this further, I
> think implementing a simple example that uses the relevant bits of the
> CMake code base to search for strings in files is the next step in the
> process leading to a Wine bug report, and I would be happy to help in
> any way I can with moving that process along.
>
>
> 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
> __________________________


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

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

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.