MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013803CMakeCMakepublic2012-12-19 10:312016-06-10 14:31
ReporterMichael Rolnik 
Assigned ToKitware Robot 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0013803: Ninja: cmake generates RSP_FILE with back slashes for ninja
DescriptionCMake when generating ninja build system creates C_STATIC_LIBRARY_LINKER_RSP_FILE variable with backslashes.
ar does not know how to handle backslashes.
the build fails.
Steps To Reproduce- create OBJECT library
- create a library out of it
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt CMakeLists.txt (433) 2013-12-03 00:19
https://public.kitware.com/Bug/file/4992/CMakeLists.txt
Issue History
Date ModifiedUsernameFieldChange
2012-12-19 10:31Michael RolnikNew Issue
2013-01-05 02:46Peter KuemmelSummarycmake generates RFC_FILE with back slashes for ninja => cmake generates RSP_FILE with back slashes for ninja
2013-02-09 07:00Peter KuemmelSummarycmake generates RSP_FILE with back slashes for ninja => Ninja: cmake generates RSP_FILE with back slashes for ninja
2013-03-09 06:28Peter KuemmelNote Added: 0032555
2013-03-09 06:28Peter KuemmelStatusnew => backlog
2013-12-02 07:36Janne RönkköNote Added: 0034622
2013-12-02 10:24Peter KuemmelNote Added: 0034671
2013-12-03 00:19Janne RönkköFile Added: CMakeLists.txt
2013-12-03 00:38Janne RönkköNote Added: 0034684
2014-04-13 09:26Peter KuemmelNote Added: 0035685
2014-06-10 07:47Thomas BernardNote Added: 0036147
2014-06-10 09:35Thomas BernardNote Added: 0036150
2016-06-10 14:28Kitware RobotNote Added: 0042174
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0032555)
Peter Kuemmel   
2013-03-09 06:28   
Bug is not new any more, move to backlog for later processing.
(0034622)
Janne Rönkkö   
2013-12-02 07:36   
I'm also experiencing this issue.

I found an email post by Matteo Franchin (http://www.cmake.org/pipermail/cmake/2013-January/053362.html [^]) describing the same issue.

I was able to avoid the problem by adding -DCMAKE_COMPILER_IS_MINGW=1 to CMake command line arguments
(0034671)
Peter Kuemmel   
2013-12-02 10:24   
Could you upload a small example to reproduce the error?
(0034684)
Janne Rönkkö   
2013-12-03 00:38   
I added the example CMakeLists.txt to the bug. I have been using Ninja generator.

The bug is not reproducible with official MinGW compilers. We are using self-built MinGW ARM compiler here (and I can not upload that compiler for you).

To reproduce the issue you might need to increase the file count limit (that is 200) in that file until the files are not passed to ar as command line arguments anymore but as .rsp file (i.e. the command line parameters for ar contains something like @CMakeFiles/testlib.rsp).

So for some reason CMake does not detect that the rsp file should contain double backslashes.

I also checked sources for CMake 2.8.12.1 but the only thing triggering this behaviour seems to be the case when CMAKE_COMPILER_IS_MINGW is set. In any case the rsp files work for the MinGW downloaded from mingw.org without manually enablidgn CMAKE_COMPILER_IS_MINGW but for our self-bult MinGW crosscompiler it does not.

The compiler information is:

> arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc.exe (crosstool-NG hg+unknown-TIMESTAMP) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and

> arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\gcc-4.7.3-glibc-2.17\arm-none-linux-gnueabi\bin\arm-none-linux-gnueabi-gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gcc-4.7.3-glibc-2.17/arm-none-linux-gnueabi/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper.exe
Target: arm-none-linux-gnueabi
Configured with: /path/to/src/gcc-4.7.3/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-host_w64-mingw32 --target=arm-none-linux-gnueabi --prefix=/opt/crosstool/gcc-4.7.3-glibc-2.17/arm-none-linux-gnueabi --with-sysroot=/opt/crosstool/gcc-4.7.3-glibc-2.17/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot --enable-languages=c,c++ --with-cpu=cortex-a8 --with-float=softfp --with-pkgversion='crosstool-NG hg+unknown-20130617.144220' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-mpfr=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-mpc=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-ppl=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-cloog=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-libelf=/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm -L/path/to/targets/arm-none-linux-gnueabi/buildtools/complibs-host/lib -lpwl' --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch --disable-nls --disable-multilib --with-local-prefix=/opt/crosstool/gcc-4.7.3-glibc-2.17/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.3 (crosstool-NG hg+unknown-TIMESTAMP)
(0035685)
Peter Kuemmel   
2014-04-13 09:26   
CMake could not know that the compiler behaves like MinGW, so you have to tell it cmake somewhere.
Does setting CMAKE_COMPILER_IS_MINGW in the cross-compile file solve the issue?

AFAIK MinGW stands for GCC producing Windows code, not for GCC compilers running on Windows in general.
(0036147)
Thomas Bernard   
2014-06-10 07:47   
I have a similar issue with resource file includes when using the ninja generator.

The problem I'm facing is different, but I think the cause is the same.

I'm using visual studio to compile an exe and a dll which both have references to .rc files. The resource compiler rules are created correctly except for the FLAGS part of the entry. The include paths all contain / instead of \ . This prevents the resource compiler to find the necessary files.

Setting the CMAKE_COMPILER_IS_MINGW solved the problem, but it's counter intuitive and an automatism to make this work out of the box should be implemented. With other generators it works perfectly.
(0036150)
Thomas Bernard   
2014-06-10 09:35   
I guess this was false hope, setting CMAKE_COMPILER_IS_MINGW made all the other entries look bad. I had then consistent behavior (all / instead of \) for the flag entries generated, regardless of compiler, linker or resource compiler.
(0042174)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.