[CMake] Linker command line length issues when cross-compiling from Windows->Linux

Eric Gross eric.gross at ni.com
Wed Feb 6 11:44:58 EST 2013


Hi David,

> From: David Carricajo <david.carricajo at gmail.com>
> To: Eric Gross <eric.gross at ni.com>
> Cc: cmake at 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


More information about the CMake mailing list