Hi David, > From: David Carricajo <david.carric...@gmail.com> > To: Eric Gross <eric.gr...@ni.com> > Cc: cmake@cmake.org > Date: 02/06/2013 07:31 AM > Subject: Re: [CMake] Linker command line length issues when cross- > compiling from Windows->Linux > <...snip...> > I've come across this limitation only for Cygwin, since you don't > mention where did you get CMake, it's a better approach to use the > one provided by the Cygwin distribution instead. As for MingGW, by > using CMake 2.8.9 and MinGW x86_64-w64-mingw32 (reads mingw 32 bits > toolchain in windows to build windows 64 bits apps) i was able to > build projects i couldn't do with Cygwin targeted Makefiles. I've no > idea why Makefiles generated for cygwin didn't use response files > while MinGW ones did.
Ah, good idea to try cygwin's CMake. My recollection is that when cygwin binaries call another cygwin binary they detect this condition and pass the arguments via an internal shared memory mechanism rather than the standard environment. This might work around the issue. I'll try this out but I'd like to avoid it as our build system doesn't actually use a local copy of cygwin but rather a subset of it from a toolchain that is part of our build system. I very much doubt that CMake is included in that and might be hard since it contains more than just binaries. Using binaries from a local installation of cygwin can cause issues if it doesn't match the one in the build system. The dependency for builds on a local CMake installation is therefore much easier to handle than one of a Cygwin install. >> It appears that the generated Makefiles are passing all the objects >> on the command line rather than using a response file. Googling the >> CMake email lists seems to indicate that on Windows this is worked >> around already in the platform-specific files used by CMake and it >> uses a response file there. I'm guessing that code is not being used >> here for me because I am cross-compiling. Is this correct? Is there >> any way to force it to use that same mechanism? > > No clue, i'm also interested. So I did manage to get this working... I copied/modified some block of code from the Windows-GNU.cmake (which does support response files) into the Linux-GNU.cmake file and it made it start using response files. The block I added was within the "macro(__linux_compiler_gnu lang)" section: set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1) set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 1) # We prefer "@" for response files but it is not supported by gcc 3. execute_process(COMMAND ${CMAKE_${lang}_COMPILER} --version OUTPUT_VARIABLE _ver ERROR_VARIABLE _ver) if("${_ver}" MATCHES "\\(GCC\\) 3\\.") if("${lang}" STREQUAL "Fortran") # The GNU Fortran compiler reports an error: # no input files; unwilling to write output files # when the response file is passed with "-Wl,@". set(CMAKE_Fortran_USE_RESPONSE_FILE_FOR_OBJECTS 0) else() # Use "-Wl,@" to pass the response file to the linker. set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG "-Wl,@") endif() # The GNU 3.x compilers do not support response files (only linkers). set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 0) elseif(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS) # Use "@" to pass the response file to the front-end. set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG "@") endif() Now, it seems like this change isn't just useful for Windows. Searching on google reveals that some people appear to run into this limitation on some Linux systems due to some restrictions on command line length as well. I haven't tested how CMake responds to these flags when actually building on Linux (as opposed to cross-compiling to Linux from Windows), but it seems like they should be able to be supported as well. Does this like a reasonable feature to request to be added? Thanks, Eric -- 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://www.cmake.org/mailman/listinfo/cmake