[Cmake] compiling and testing CMake with gcc -mno-cygwin for MinGW

Wheeler, Frederick W (Research) wheeler at crd.ge.com
Mon, 26 Jan 2004 08:33:53 -0500


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 
>