Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#8596 closed feature request (fixed)

Add support for "reponse files" to workaround Windows command line length limitations

Reported by: joeyhess Owned by: snoyberg
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking: #9685
Related Tickets: #10777 #9685 Differential Rev(s):
Wiki Page:


I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link.

I will attach the output of cabal build --ghc-options=-v for a failing and a successful build.

I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry.

Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module?

Attachments (2)

log.failed-with-webapp (95.4 KB) - added by joeyhess 6 years ago.
failed link
log.nowebapp (75.8 KB) - added by joeyhess 6 years ago.
successful link

Download all attachments as: .zip

Change History (16)

Changed 6 years ago by joeyhess

Attachment: log.failed-with-webapp added

failed link

Changed 6 years ago by joeyhess

Attachment: log.nowebapp added

successful link

comment:1 Changed 6 years ago by refold

gcc has a feature called response files that allows to work around this problem.

comment:2 Changed 6 years ago by joeyhess

Thanks, that's really helpful.

Is there any interface in ghc to use response files? If not, please consider this a feature request. ;)

comment:3 Changed 6 years ago by joeyhess

I have verified that I can use response files to link my program. Currently generating the file from ghc -v output:

  cabal build --ghc-options='-v -keep-tmp-files' > build.log 2>&1
  grep '"dist\\build\\git-annex\\git-annex.exe"' build.log | sed -e 's/^"[^"]*" //' -e 's/\\/\//g' > gcc.opt
  gcc @gcc.opt

Refold probably saved me weeks of refactoring into libraries.

Last edited 6 years ago by joeyhess (previous) (diff)

comment:4 Changed 5 years ago by thomie

Architecture: x86Unknown/Multiple
Summary: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)"Add support for "reponse files" to workaround Windows command line length limitations
Type: bugfeature request

comment:5 Changed 4 years ago by Phyx-

comment:6 Changed 4 years ago by snoyberg

Owner: set to snoyberg

comment:7 Changed 4 years ago by snoyberg

I've sent a diff for this:

Unfortunately, I haven't been successful yet at building GHC on Windows, so I haven't tested there yet. If someone who's experienced this problem has success building with that change, please report back.

comment:8 Changed 4 years ago by philipp

Hi Michael,

thanks for your patch. I compiled ghc 7.10.2 with your patch on windows.

Unfortunately, I still get an error when I try to build my project. While trying to link the executable, I get

gcc.exe: error: CreateProcess: No such file or directory

Any ideas what the reason could be? If I can help in diagnosing this further, please let me know.

comment:9 Changed 4 years ago by snoyberg

Yes, the problem is that the GCC toolchain that ships with GHC 7.10 does not itself use response files internally when calling itself for linking. We diagnosed this here, including a short-term (hacky) fix:

In order to get this included in GHC 7.10.3, has been set to merge status. Once that's backported, the ghc-7.10 branch should just work.

comment:10 Changed 4 years ago by philipp


I can happily confirm that using the new version of mingw solved the problem for me :)

comment:11 Changed 4 years ago by Ben Gamari <ben@…>

In 296bc70/ghc:

Use a response file for linker command line arguments #10777

On Windows, we're constrained to 32k bytes total for command line
arguments.  When building large projects, this limit can be exceeded.
This patch changes GHC to always use response files for linker
arguments, a feature first used by Microsoft compilers and added to GCC
(over a decade ago).

Alternatives here include:

* Only use this method on Windows systems
* Check the length of the command line arguments and use that to decide
  whether to use this method

I did not pursue either of these, as I believe it would make the patch
more likely to break in less tested situations.

Test Plan:
Confirm that linking still works in general. Ideally: compile a very
large project on Windows with this patch. (I am attempting to do that
myself now, but having trouble getting the Windows build tool chain up
and running.)

Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx

Reviewed By: thomie, bgamari, Phyx

Subscribers: erikd, awson, #ghc_windows_task_force, thomie

Differential Revision:

GHC Trac Issues: #8596, #10777

comment:12 Changed 4 years ago by bgamari

Resolution: fixed
Status: newclosed

comment:13 Changed 4 years ago by thomie

Milestone: 8.0.1

comment:14 Changed 4 years ago by gintas

Blocking: 9685 added
Note: See TracTickets for help on using tickets.