LLD Command Line Length Error

Project Infrastructure LLVM Dev List Archives
1

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

2

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; }

3

Such a change looks good to me; we should be handling response files quite well these days so this should be safe.

Do you have time to make a proper patch out of this? Otherwise I can try to pick it up in a while, but I'm a little short on time at the moment.

// Martin

4

I landed it in r367733. I couldn’t figure out how to write a test for it because -### runs before response file expansion.

5

Thanks! Yes, I guess making a test for this would be more effort than what makes sense.

// Martin