[Cmake] compiling and testing CMake with gcc -mno-cygwin
for MinGW
William A. Hoffman
billlist at nycap.rr.com
Mon, 26 Jan 2004 13:38:57 -0500
I have found some problems with putenv/getnenv code in cmake.
I have checked in a fix and all the tests pass. I was
not able to get testdriver2 to hang. But, perhaps
my fixes will fix that problem as well. I have seen a problem
recently on cygwin, where I have to hit <enter> in the window
where ctest is running, and then things continue.
Did you try that?
Here is the env I used:
export CC="`cygpath -m /usr/bin/gcc-2.exe`"
export CXX="`cygpath -m /usr/bin/g++-2.exe`"
export CFLAGS="-mno-cygwin"
export CXXFLAGS="-mno-cygwin"
export LDFLAGS="-mno-cygwin"
../CMake-nmake-dashboard/bin/cmake -G"Unix Makefiles" ../CMake
At 08:33 AM 1/26/2004, Wheeler, Frederick W (Research) wrote:
>Bill, CMake List,
>
>I'm having one last odd problem with CMake and gcc -mno-cygwin.
>
>With the recent changes to CMakeDetermineCCompiler.cmake my gcc
>-mno-cygwin MinGW build now works much better. The build finishes
>with no errors, some warnings. All tests pass, but not in the usual
>way. After the build, if I do "make test", test "testdriver2" hangs.
>As I slowly eliminated ADD_TEST commands for hanging tests I got the
>hunch that the tests that were failing were ones that used the same
>build directory as a previous test. I can get all tests to pass by
>wiping the Tests and Example dirs before each test. All tests pass,
>one at a time, using this:
>
> touch stamp
> for TEST in $TESTS; do
> echo test: $TEST
> echo removing Tests and Example dirs
> find Tests Example -type f -exec $TOP/cmake_bld_min/bin/cmake -E remove
>-f {} \;
> # rm -rf Tests Example
> echo files newer than stamp
> find . -type f -newer stamp -print
> echo run just one test
> # "/cygdrive/c/Program Files/CMake/bin/ctest" -R "^$TEST\$"
> $TOP/cmake_bld_min/bin/ctest -R "^$TEST\$"
> echo done
> echo
> done
>
>I thought maybe cmake -E remove was failing to remove something, so
>that is why I tried using it as you can see above. Worked fine so
>that is probably not part of the problem.
>
>Given the observation about needed to remove dirs between tests does
>anyone have an idea about what might be going wrong, or what else I
>could try?
>
>It's difficult to figure out where the tests hang. The hanging
>commands I think are windows execs. Any suggestions here?
>
>Once I get the hangs to stop I can turn on a Cmake MinGW dashboard
>build.
>
>Fred Wheeler
>
>
>> -----Original Message-----
>> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
>> Sent: Thursday, January 22, 2004 9:15 AM
>> To: Wheeler, Frederick W (Research); CMake List (E-mail)
>> Subject: RE: [Cmake] compiling and testing CMake with gcc -mno-cygwin
>> for MinGW
>>
>>
>> Well, that is why we have the test with one config and with
>> two configs
>> to catch this kind of problem. I don't think it can be
>> fixed by changing
>> the order in the cmGlobalGenerator.cxx. The problem is that
>> CMAKE_C_FLAGS
>> can not be initialized until we know what compiler it is.
>> Often times the
>> compiler file sets special flags for the CMAKE_C_FLAGS.
>>
>> I think this can be fixed if we change
>> CMakeDeterminCCompiler.cmake to do this:
>>
>> IF(CMAKE_C_FLAGS)
>> SET(CMAKE_BOOT_C_FLAGS ${CMAKE_C_FLAGS})
>> ELSE(CMAKE_C_FLAGS)
>> SET(CMAKE_BOOT_C_FLAGS $ENV{CFLAGS})
>> ENDIF(CMAKE_C_FLAGS)
>> EXEC_PROGRAM(${CMAKE_C_COMPILER} ARGS ${CMAKE_BOOT_C_FLAGS}
>> -E "\"${CMAKE_ROOT}/Modules/CMakeTestGNU.c\"" OUTPUT_VARIABLE
>> CMAKE_COMPILER_OUTPUT RETURN_VALUE CMAKE_COMPILER_RETURN)
>>
>>
>> Can you try it? If it works for you I will check it in.
>>
>> -Bill
>>
>> At 05:13 PM 1/21/2004, Wheeler, Frederick W (Research) wrote:
>>
>> >When ComplexOneConfig is configured and cmake is parsing
>> >Tests/Complex/CMakeLists.txt, WIN32, UNIX and CYGWIN are set
>> instead of
>> >WIN32 and MINGW. This leads to the test failing because the registry
>> >setting section is skipped. The problem stems from the
>> option -mno-cygwin
>> >not being used at line 51 (+/- 1) of
>> CMakeDetermineCCompiler.cmake because
>> >CMAKE_C_FLAGS is unset there. It looks like
>> >CMakeSystemSpecificInformation.cmake sets CMAKE_C_FLAGS from
>> env var CFLAGS.
>> >Debugging MESSAGE() commands I've added indicate that
>> >CMakeSystemSpecificInformation.cmake runs and sets
>> CMAKE_C_FLAGS after
>> >CMakeDetermineCCompiler.cmake has already run.
>> cmGlobalGenerator.cxx seems
>> >to be the place to make a fix.
>> >
>> >The Complex test passes fine, so this problem is brought on
>> by the omission
>> >of the --build-two-config option to ctest.
>> >
>> >CMAKE_C_FLAGS ends up set in the cache ... but is not set in time for
>> >CMakeDetermineCCompiler.cmake.
>> >
>> >0% pwd
>> >/home/200006507/dev/cmake_bld_min/Tests/ComplexOneConfig
>> >0% grep CMAKE_C_FLAGS *
>> >CMakeCache.txt:// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo
>> >MinSizeRel.
>> >CMakeCache.txt:CMAKE_C_FLAGS:STRING=' -mno-cygwin '
>> >CMakeCache.txt:CMAKE_C_FLAGS_DEBUG:STRING=-g
>> >CMakeCache.txt:CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os
>> >CMakeCache.txt:CMAKE_C_FLAGS_RELEASE:STRING=-O3
>> >CMakeCache.txt:CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g
>> >CMakeCache.txt://Advanced flag for variable: CMAKE_C_FLAGS
>> >CMakeCache.txt:CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
>> >CMakeCache.txt://Advanced flag for variable: CMAKE_C_FLAGS_DEBUG
>> >CMakeCache.txt:CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
>> >CMakeCache.txt://Advanced flag for variable: CMAKE_C_FLAGS_MINSIZEREL
>> >CMakeCache.txt:CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
>> >CMakeCache.txt://Advanced flag for variable: CMAKE_C_FLAGS_RELEASE
>> >CMakeCache.txt:CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
>> >CMakeCache.txt://Advanced flag for variable:
>> CMAKE_C_FLAGS_RELWITHDEBINFO
>> >CMakeCache.txt:CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
>> >
>> >Fred Wheeler
>> >
>> >> -----Original Message-----
>> >> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
>> >> Sent: Wednesday, January 21, 2004 11:39 AM
>> >> To: Wheeler, Frederick W (Research)
>> >> Subject: RE: [Cmake] compiling and testing CMake with gcc
>> -mno-cygwin
>> >> for MinGW
>> >>
>> >>
>> >> You can do ctest -V to get a more verbose output.
>> >> That should show the problem.
>> >>
>> >>
>> >> -Bill
>> >>
>> >>
>> >> At 11:14 AM 1/21/2004, Wheeler, Frederick W (Research) wrote:
>> >> >Thanks Bill. That helps several tests. Now I get what you
>> >> see below.
>> >> >Seems to hang on testdriver2. I'll look into this
>> further, probably
>> >> >tonight.
>> >> >
>> >> >Fred
>> >> >
>> >> >Testing CommandLineTest Passed
>> >> >Testing CustomCommand Passed
>> >> >Testing FindPackageTest Passed
>> >> >Testing SystemInformation Passed
>> >> >Testing StringFileTest Passed
>> >> >Testing TryCompile Passed
>> >> >Testing simple Passed
>> >> >Testing conly Passed
>> >> >Testing X11 Passed
>> >> >Testing LoadedCommand Passed
>> >> >Testing LoadedCommandOneConfig Passed
>> >> >Testing complex Passed
>> >> >Testing complexOneConfig ***Failed
>> >> >Testing Example Passed
>> >> >Testing testing Passed
>> >> >Testing wrapping Passed
>> >> >Testing testdriver1 Passed
>> >> >Testing testdriver2
>> >> >
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
>> >> >> Sent: Wednesday, January 21, 2004 10:48 AM
>> >> >> To: Wheeler, Frederick W (Research); CMake List (E-mail)
>> >> >> Subject: Re: [Cmake] compiling and testing CMake with gcc
>> >> -mno-cygwin
>> >> >> for MinGW
>> >> >>
>> >> >>
>> >> >> Try adding this:
>> >> >> export LDFLAGS="-mno-cygwin"
>> >> >>
>> >> >>
>> >> >> -Bill
>> >> >>
>> >> >> At 02:08 PM 1/20/2004, Wheeler, Frederick W (Research) wrote:
>> >> >> >CMake List:
>> >> >> >
>> >> >> >I've been trying to get CMake to build and pass it's
>> >> tests in Cygwin
>> >> >> >using gcc with the -mno-cygwin option to use the MinGW
>> libraries
>> >> >> >instead of Cygwin. The build works fine now (thanks to recent
>> >> >> >CMakeDetermineCCompiler.cmake change), but some of the
>> tests fail.
>> >> >> >Part of the problem (perhaps all of the problem?) is that the
>> >> >> >-mno-cygwin option is not used everywhere it needs to be
>> >> during the
>> >> >> >CMake tests.
>> >> >> >
>> >> >> >Here is how I configure and build CMake. Works fine.
>> >> >> >
>> >> >> ># use precompiled installed CMake to configure cmake
>> >> >> ># configure cannot be used for a MinGW build, only Unix
>> >> >> >"/cygdrive/c/Program Files/CMake/bin/cmake" \
>> >> >> > -G"Unix Makefiles" \
>> >> >> > -DCMAKE_INSTALL_PREFIX:PATH="`cygpath -m
>> $TOP/cmake_usr_min`" \
>> >> >> > -DCMAKE_C_COMPILER:FILEPATH="`cygpath -m /usr/bin/gcc`" \
>> >> >> > -DCMAKE_CXX_COMPILER:FILEPATH="`cygpath -m /usr/bin/g++`" \
>> >> >> > -DCMAKE_C_FLAGS:STRING="-mno-cygwin -Wall -O2 -g" \
>> >> >> > -DCMAKE_CXX_FLAGS:STRING="-mno-cygwin -Wall -O2 -g" \
>> >> >> > "`cygpath -m $TOP/cmake_src`"
>> >> >> >make
>> >> >> >
>> >> >> >If I just do "make test" next I get a lot of console windows
>> >> >> >explaining some illegal instruction error. (Details
>> >> >> available.) This
>> >> >> >problem is mostly fixed by these environment settings.
>> >> >> >
>> >> >> >export CC="`cygpath -m /usr/bin/gcc`"
>> >> >> >export CXX="`cygpath -m /usr/bin/g++`"
>> >> >> >export CFLAGS="-mno-cygwin"
>> >> >> >export CXXFLAGS="-mno-cygwin"
>> >> >> >
>> >> >> >With these settings, the tests are using the -mno-cygwin
>> >> >> option enough
>> >> >> >to at least avoid the illegal instruction errors. All
>> >> tests except
>> >> >> >these pass:
>> >> >> >
>> >> >> >The following tests FAILED:
>> >> >> > LoadedCommand
>> >> >> > LoadedCommandOneConfig
>> >> >> > complex
>> >> >> > complexOneConfig
>> >> >> > kwsys
>> >> >> >
>> >> >> >What do these tests have in common?
>> >> >> >
>> >> >> >I dug down into the LoadedCommand test a bit. This
>> snippet should
>> >> >> >show how there is an attempt to link a shared lib without the
>> >> >> >-mno-cygwin option. Note how the lib builds when I
>> >> manually add the
>> >> >> >-mno-cygwin option.
>> >> >> >
>> >> >> >0% pwd
>> >> >>
>> >/home/200006507/dev/cmake_bld_min/Tests/LoadCommand/CMakeCommands
>> >> >> >0% make
>> >> >> >Building shared module cmCMAKE_TEST_COMMAND.dll...
>> >> >> >cmTestCommand.o(.text+0xb16):cmTestCommand.c: undefined
>> >> reference to
>> >> >> >`__imp___iob'
>> >> >> >collect2: ld returned 1 exit status
>> >> >> >make[1]: *** [cmCMAKE_TEST_COMMAND.dll] Error 1
>> >> >> >make: *** [default_target] Error 2
>> >> >> >2% make -n cmCMAKE_TEST_COMMAND.dll
>> >> >> >echo "Building shared module cmCMAKE_TEST_COMMAND.dll..."
>> >> >> >C:/cygwin/home/200006507/dev/cmake_bld_min/bin/cmake.exe
>> >> -E remove -f
>> >> >> >"`pwd`"/cmCMAKE_TEST_COMMAND.dll
>> >> >> >C:/cygwin/bin/gcc.exe -shared -o
>> >> "`pwd`"/cmCMAKE_TEST_COMMAND.dll
>> >> >> >cmTestCommand.o
>> >> >> >0% C:/cygwin/bin/gcc.exe -mno-cygwin -shared -o
>> >> >> >"`pwd`"/cmCMAKE_TEST_COMMAND.dll cmTestCommand.o
>> >> >> >0% ls cmCMAKE_TEST_COMMAND.dll
>> >> >> >cmCMAKE_TEST_COMMAND.dll
>> >> >> >0%
>> >> >> >
>> >> >> >I don't yet know how to fix this and I don't know whether
>> >> it is worth
>> >> >> >fixing. If anyone has any suggestions I will try them.
>> >> I want to at
>> >> >> >least post what I have found.
>> >> >> >
>> >> >> >It seems to me that the basic problem is that -mno-cygwin is
>> >> >> a special
>> >> >> >kind of critical option that essentially specifies which
>> >> compiler you
>> >> >> >are using. I need a way to tell the tests that they must
>> >> always use
>> >> >> >this option in addition to whatever other options they
>> >> >> ordinarily wish
>> >> >> >to use for gcc. Besides the environment variables CC, CXX,
>> >> >> CFLAGS and
>> >> >> >CXXFLAGS I do not see any other way to pass compiler
>> >> >> arguments down to
>> >> >> >the CMake tests. CMAKE_C_COMPILER and CMAKE_CXX_COMPILER
>> >> cannot have
>> >> >> >this option tacked on. (I forget exactly what
>> happens, but recall
>> >> >> >this not working.) The CMAKE_*_FLAGS options used for
>> >> building CMake
>> >> >> >are not necessarily used by the tests, for good reason -
>> >> so that is
>> >> >> >not an avenue.
>> >> >> >
>> >> >> >Comments or suggestions welcome.
>> >> >> >
>> >> >> >Fred Wheeler
>> >> >> >_______________________________________________
>> >> >> >Cmake mailing list
>> >> >> >Cmake at www.cmake.org
>> >> >> >http://www.cmake.org/mailman/listinfo/cmake
>> >> >>
>> >>
>> >_______________________________________________
>> >Cmake mailing list
>> >Cmake at www.cmake.org
>> >http://www.cmake.org/mailman/listinfo/cmake
>>