[llvm-dev] LLD Command Line Length Error

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 30 15:41:02 PDT 2019


I think the bug is that clang won't use a response file unless it thinks
the tool it is running supports them. The MinGW linker tool doesn't claim
to support response files today. I think this would be a simple fix:

$ git diff
diff --git a/clang/lib/Driver/ToolChains/MinGW.h
b/clang/lib/Driver/ToolChains/MinGW.h
index 08298e910eb..41c466337b7 100644
--- a/clang/lib/Driver/ToolChains/MinGW.h
+++ b/clang/lib/Driver/ToolChains/MinGW.h
@@ -34,7 +34,7 @@ public:

 class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
 public:
-  Linker(const ToolChain &TC) : Tool("MinGW::Linker", "linker", TC) {}
+  Linker(const ToolChain &TC) : Tool("MinGW::Linker", "linker", TC,
RF_Full) {}

   bool hasIntegratedCPP() const override { return false; }
   bool isLinkJob() const override { return true; }

On Wed, Jul 24, 2019 at 6:43 AM Harry Wagstaff via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> I'm currently trying to use clang to build a largish project on Windows
> using MinGW. I'm currently performing all of the compilation using g++, and
> then linking with clang++ with lld (due to separate issues I'm having with
> compiling with clang with MinGW). Compiling with g++ and then linking with
> clang+lld seems to work fine for small programs.
>
> I'm invoking clang++ something like this:
> $ clang++ -target x86_64-pc-windows-gnu -fuse-ld=lld {lots of linker
> parameters} @{path to a response file}
>
> I then receive an error message:
> clang++: error: unable to execute command: Couldn't execute program '(path
> to ld.lld)': The filename or extension is too long.
>
> If I then rerun clang++ with -v, I get the full command line passed to lld
> (which is approximately 44KB). It looks like there was previously a patch
> that tried to address this issue for certain platforms (
> https://reviews.llvm.org/rL334295) but this doesn't seem to have fixed
> the issue in my case.
>
> Is there some way to work around this issue? Since the decision of whether
> to use a response file or not seems to be based on a heuristic ('keep half
> of the space available for environment variables'), perhaps an option
> should be provided to force a response file to be used?
>
> Thanks,
> Harry Wagstaff
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/0fabc908/attachment.html>


More information about the llvm-dev mailing list