Here are the results requested by Brad:
bash.exe-3.1$ ls
CMakeFortranCompilerId.F a.exe info.cmake
bash.exe-3.1$ cat info.cmake
file(STRINGS a.exe _strings LIMIT_COUNT 4 REGEX "INFO:")
foreach(info ${_strings})
message(STATUS "[${info}]")
endforeach()
bash.exe-3.1$ /z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe -P
info.cmake
bash.exe-3.1$ /z/home/wine/newstart/bootstrap_cmake/install_4.7.0/bin/cmake.exe
-P info.cmake
-- [INFO:compiler[GNU]INFO:platform[]]
So these results show a clear difference between the two CMake
versions on Wine-1.5.15; the file(STRINGS,...) command fails to work
properly (delivers an empty _strings) while the bootstrapped version
works properly.
(Note, I am now using MinGW-4.7.0 rather than the MinGW-4.5.2 results
I discussed before. Exhaustive CMake, PLplot, ephcom, and te_gen
tests show that both versions of MinGW are reliable on Wine-1.5.15 so
long as you use the bootstrapped version of CMake above, and I have
decided to go with the 4.7.0 version from now on.)
Just in case the problem was caused by the file hash issue that Clint Stimpson
found a few years back for Wine, I also copied a.exe to b.exe, and ran
the equivalent commands with appropriately modified info.cmake to look
at b.exe, but the results were the same; nothing for downloaded
CMake-2.8.9 while the bootstrapped version gave the expected result.
Now that we have a clear fundamental difference between the two cmake
versions can you simplify the test case a lot more? I am thinking along
the lines of a simple C++ test programme (with one version compiled
there and one version compiled here) that attempts to do the same
thing as above.
I also hope Clint Stimpson (who I put on the CC list) is willing to
start participating in this conversation since he has some Wine
expertise that he can bring to the table. Perhaps once you
have simplified the example still further, he will be able
to spot the area of Wine that could be the issue.
Note also, that whatever the issue is, it does not occur for the
command generated by CMake to link C libraries. So I would look
carefully at how that link command is generated for C versus Fortran
libraries to see if there are any gratuitous differences that could be
eliminated.
Finally, I very much appreciate the CMake developers' continued
willingness to spend some effort on Wine platform concerns. I am very
happy to cooperate in any way possible to get to the bottom of the
current issue on that platform, because other than this one issue
(which can be worked around by using the bootstrapped version of
CMake) it is running very smoothly for me for a number of exhaustive
tests. Nevertheless, if there are a number of additional tests you
would like to run for the present case, then you might want to
consider running them on your own Wine platform rather than attempting
to debug the problem slowly at one remove through me.
If you want to pursue that option further, here are the two absolutely
straightforward steps you have to do to set up a Wine platform
on Linux.
(1) You need to build Wine-1.5.15 under Linux making sure you have
ncurses support included in the configuration step. See
http://www.winehq.org/download/ and
http://wiki.winehq.org/Recommended_Packages for clear instructions
which I followed myself for my Debian wheezy platform. Alternatively,
that first page may give you access to binary versions of Wine-1.5.15
that you could install for your particular Linux distribution.
(2) Download and install MinGW-4.7.0 and the corresponding latest MSYS
on Wine using
wineconsole mingw-get-inst-20120426.exe
Make sure you check the box that says update to the latest
versions (which gets you MinGW-4.7.0), and check the box for
the full MSYS tools as well (which includes bash).
That second step literally only takes 5 minutes. After that you run
all commands under bash.exe on the Wine platform using, e.g.,
wineconsole --backend=curses MinGW_4.7.0/msys/1.0/bin/bash.exe
The big advantage of that curses backend for wineconsole is you can
cut and paste to it from Linux and vice versa. To save a lot of
typing and to always have reproducible results under the bash.exe
environment, I typically source a file (using the bash . operator) to
set up all the environment variables I need, then use bash(.exe) to
execute a shell script which runs the build and install of any
software that I need. For an example of this approach see the
files I sent to David for the test case that we are still using
for comparisons.
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
