Gracefully handle super-long linker command lines

[alexcrichton]

The compiler should gracefully handle invocations of the linker which would otherwise blow the system limits. I've heard reports of this happening on both Unix and Windows, so this is a cross-platform concern.

My preference of how to implement this would be:

• Linkers typically support this method via passing arguments as @file where file is a path on the filesystem that contains a bunch of options.
• Short linker invocations should not use @file syntax for debuggability
• The compiler automatically switches to @file when the command line gets too big.
• rustc has some arbitrary limit for bytes it'll pass as arguments to Command, likely well below the platform specific limits

I don't know the precise syntax of these files, unfortunately, but I'm sure google does somewhere!

[jsgf]

The trouble is that if rustc is generating linker lines that are too long for exec (or the Windows equiv), then the chances are it's also getting a command line that is similarly long. Therefore rustc also needs to accept @args as well as generate it.

Are there cases where rustc will generate a linker line that's not proportional to its own command line (setting aside issues around -C link-arg[s])?

[jsgf]

BTW, the @ argfile syntax is pretty simple: it's basically whitespace separated with normal "" \-esc quoting rules. Commonly, args are separated by \n for readability. args files can recursively include other args files. https://sourceware.org/binutils/docs/ld/Options.html#Options

I believe MacOS's linker adds complications in that it can only be flags, not input files - but it supports a second file containing input filenames (which makes intermingling flags and files awkward), with a slightly different format (one filename per line, no quoting rules).

[alexcrichton]

Yes I think that @-syntax for rustc itself may be best in a separate bug for now to bikeshed syntax, etc. The linker is invoked with a command line of size O(size of dependency graph) where the compiler is O(number immediate dependencies), so I think this is far more likely to be a problem internally than invoking the compiler (to start out with at lesat)

[nagisa]

Some notes:

1. @file should not be removed for failed linker invocations.
2. rustc should attempt to put @file into some ramfs if there’s anything like that.

[jsgf]

@alexcrichton:

The linker is invoked with a command line of size O(size of dependency graph) where the compiler is O(number immediate dependencies),

Well, the rustc line needs to have a -Ldependency= option for each node in the dependency graph, but if they tend to be in the same directory then they can be collapsed together, so it becomes O(number-of-dirs-in-dep-graph) - which works for cargo, but not for buck because every dep tends to be in its own directory.

@nagisa:

@file should not be removed for failed linker invocations.

I'm not sure what this means. Do you mean that the arg @file is used literally if file doesn't exist?

[nagisa]

no I mean it should not remove the file, so you could look at the args when linking fails.

[alexcrichton]

@jsgf ah yes, that is a good point.

[retep998]

For Windows the limit for a command line is a hard 32,768 wchars. Fortunately for Windows, the way that we flatten the command line for CreateProcess for Command is identical to the format of link's command files, so we can just reuse that code and it'll work.

rustc should attempt to put @file into some ramfs if there’s anything like that.

@nagisa Just open the file on Windows with FILE_ATTRIBUTE_TEMPORARY and Windows will delay writing it to disk so long as memory is available.

[retep998]

Related issues: #40384 #39644

[cengiz-io]

I know we're currently looking into this but this is causing so much pain for me right now. I'll try moving my rust source folder to a shorter path.

I hope it gets fixed very soon.

😭

Can we perhaps assign some labels and look for potential takers?

[retep998]

For whoever is implementing this for msvc, could you also implement deduplication of library input at the same time? cc #38460