Linker command line is too long about fastbuild HOT 16 CLOSED

I assume you are getting this error?

FBuild: Error: Command Line Limit Exceeded (len: %u, limit: %u) '%s'\n

Some background on this functionality:

The logic currently is that response files will be used when:
a) The tool is known to support it (detected by exe name as you noted)
b) The command line exceeds the OS limit (not used always to avoid creating the response file when not needed as this saves a few ms off invocation)

In previous tests, I only managed to get the response file working with the PS4 version of Clang, so it's only enabled for that. If clang does actually support response files, that can be fixed. As you point out, since you are building your own exe, even if this helps others, it doesn't necessarily help you (if you have a different exe name).

I think we could do something like you suggest, though I'd probably alter the proposal slightly:
a) Namespace it a bit more
b) Make it a forcing function

Library( 'lib' )
{
    .LibrarianForceUseResponseFiles = true
   ...

So that the code behaviour can be like this:

bool LibraryNode::CanUseResponseFile() const
{
    if ( m_ForceUseResponseFile )
    {
        return true;
    }
    #if defined( __WINDOWS__ )
        // Generally only windows applications support response files (to overcome Windows command line limits)
        return ( GetFlag( LIB_FLAG_LIB ) || GetFlag( LIB_FLAG_AR ) || GetFlag( LIB_FLAG_ORBIS_AR ) || GetFlag( LIB_FLAG_GREENHILLS_AX ) );
    #else
        return false;
    #endif
}

The idea being that variables in the bff syntax don't have a "not-set" value that we could use, so we couldn't differentiate false from the default as opposed to being set to false.

An alternate way to manage this is to externalize the definition of the Librarian/Linker tool in the same way we do for Compiler. This way you could do this:

Librarian( 'customtool' )
{
    .LibrarianExecutable       = 'codegentool.exe'
    .LibrarianUseResponseFiles = true

In retrospect, this probably should have been the design from the start :)

Let me know what you think.

from fastbuild.

I think I agree that externalizing the librarian/linker to behave in a similar way to the compiler is probably the way to go.

I wonder if it would be valuable to be able to override the auto-detection of compiler/linker CLI to use. It would allow for custom tools like ours to specify what kind of tool FBuild thinks we are? Anything could function as front end or replacement to an actual tool at that point (I'll be it'll still need to behave somewhat like a c++ compiler/linker).

Librarian( 'customtool' )
{
    .LibrarianExecutable              = 'codegentool.exe'
    .LibrarianToolCLI                   = 'Clang' | 'MSVC' | 'GreenHills' | 'OrbisClang'
    .LibrarianUseResponseFiles  = true
}

I wonder if long-term we can generalize the bits that make it necessary to auto-detect the tool by name at all?

from fastbuild.

Interestingly a "LinkerType" option was recently added to the Exectuable()/DLL() function (including a default "auto" value which uses the exe name detection). That's pretty much what you've described.

In that case we chose not to externalize it in a new Linker() function in order to be compatible with CMake (it annoyingly invokes several different things via cmake.exe) In retrospect though, I think that was a mistake - we could have handled the cmake case by allowing the same exe to be used in multiple Linker definitions instead.

(For context: The cmake thing is users trying to make cmake capable of generating bff files. Ideally fbuild.exe will never invoke cmake (for performance reasons), but during development this allows cmake to handle some things fastbuild doesn't do natively, in the same way it does with msbuild - it generates vcxproj but cmake is called at compile time for some things)

from fastbuild.

For reference: https://github.com/fastbuild/fastbuild/pull/60/files

from fastbuild.

Interesting, well that is exactly what I'm talking about. I can look at pulling that feature into Library then, as well as adding this LibrarianForceUseResponseFiles. Unless you wan to continue down this Linker() path?

from fastbuild.

Thinking about this a bit more, I'd like to work towards doing this properly by making a new Librarian() and Linker(), but this is going to take some time (particularly so as not to break backwards compatibility).

With that in mind, do you think for now you could use "Linker" instead of "Library" in your use-case and set the .LinkerType = "orbis-ld" (or indeed "msvc" or "gcc" aught to work too)? That should activate the use of response files without any need to make code changes. Little to nothing else is currently implied by that setting other than response file use (only "orbis-ld" implies some additional slash escaping in the response file).

from fastbuild.

Yep I can work with that, although I thought that there was more command line parsing going on behind the scenes in fbuild, but if that'll work then we're good.

Thanks

from fastbuild.

Sorry, did you mean DLL instead of Library?

from fastbuild.

Sorry for the confusion. I meant try to use Executable() instead of Library() for the work around, setting the LinkerType on that.

(The confusion on my side is that in the code LinkerNode.cpp is exposed as Executable() and DLL(). You don't want to use DLL as it has some sanity checks of the command line - i.e. whether you are missing /DLL etc)

from fastbuild.

Hey, sorry for bringing this up again, but I am having the same error message using a custom nintendo clang compiler. Is there any possible workaround ?
I tried setting the LinkerType to orbis-ld but that didn't do much.
Edit (just to clarify):
I'm trying to generate a nintendo executable using FastBuild. I copied all the commands from our visual studio project, it compiles everything but as soon as it needs to link I get the command line limit error.

from fastbuild.

"orbis-ld" is not a valid LinkerType, you probably want to try "clang-orbis" (valid types are documented here: http://fastbuild.org/docs/functions/executable.html) On a related note, it looks as though there is a bug where setting an invalid type will not report an error.

If the above works, then we can probably trivially add detection for the nintendo flavor of linker in this function LinkerNode::DetermineLinkerTypeFlags here https://github.com/fastbuild/fastbuild/blob/dev/Code/Tools/FBuild/FBuildCore/Graph/LinkerNode.cpp.

from fastbuild.

Awesome, thanks for the quick reply. This fixed it.
I have another question if it's okay to post it here,
Is it possible to use the compiler stage as both compiling and linking ? The compiler I use sets up the linker internally and I can't seem to remove the linker executable in the Executable section.

Thanks again :)

from fastbuild.

@AntoineConffx I think it would be best to open new issue for any problems you have so that we can avoid noise in this thread.

from fastbuild.

So I just encountered this again after all this time... I went searching to see what could be done, only to discover that I committed to resolving this 4 years ago! Clearly I forgot, ugh!

from fastbuild.

I've made a follow up change https://travis-ci.com/github/fastbuild/fastbuild/builds/180975249 that allows Compiler, Librarian and Executable/DLL to set a "ForceResponseFile" option which will cause them to use a response file regardless of command line length.

• Compiler() response file use can be forced with .ForceResponseFile
• Library() response file use can be forced with .LibrarianForceResponseFile
• Executable()/DLL() response file use can be forced with .LinkerForceResponseFile

This change will be in the next release (v1.02). I think that will resolve this issue. I'll leave this issue open until that version is released.

(Note that it would still be of value to improve automated detection for additional toolchains (like for the Switch-flavored Clang) and I'll happily accept PRs that extend the detection)

from fastbuild.

v1.02 has now been released which includes new functionality to resolve this issue as mentioned above. Should there be any remaining issues, please let me know.

from fastbuild.