llvm dev - Aug 2019 - LLD Command Line Length Error

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190724/2c3f0b1a/attachment.html>

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>

On Tue, 30 Jul 2019, Reid Kleckner wrote:
> 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; }
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