go: syscall: Go Build Fails on Windows With Long Paths
Opening by request in #3358
What version of Go are you using (go version)?
go version go1.8beta2 windows/amd64
What operating system and processor architecture are you using (go env)?
Win64
What did you do?
Tried to compile several files, many with long names, in a folder via go build
What did you expect to see?
Successful compile
What did you see instead?
go build github.com/cretz/myproj: C:\dls\go1.8\go\pkg\tool\windows_amd64\compile.exe: fork/exec C:\dls\go1.8\go\pkg\tool\windows_amd64\compile.exe: The filename or extension is too long.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 53 (38 by maintainers)
Commits related to this issue
- Move gateway unsupported functions into a common struct. This is done to avoid repeated declaration of not-implemented functions for each gateway. It also avoids a possible bug in go https://github.c... — committed to harshavardhana/minio by harshavardhana 7 years ago
- Move gateway unsupported functions into a common struct. This is done to avoid repeated declaration of not-implemented functions for each gateway. It also avoids a possible bug in go https://github.c... — committed to harshavardhana/minio by harshavardhana 7 years ago
- Move gateway unsupported functions into a common struct. This is done to avoid repeated declaration of not-implemented functions for each gateway. It also avoids a possible bug in go https://github.c... — committed to harshavardhana/minio by harshavardhana 7 years ago
- Move gateway unsupported functions into a common struct. (#5009) This is done to avoid repeated declaration of not-implemented functions for each gateway. It also avoids a possible bug in go https:... — committed to minio/minio by harshavardhana 7 years ago
- review: disable windows coverage See golang/go#18468 issue. — committed to aead/minio by deleted user 7 years ago
- Added a function to src/cmd/go/internal/work/exec.go that copies arguments into a response file if the total length of all the args is larger than the limitation imposed by windows. Also Modified runO... — committed to arizvisa/golang by arizvisa 6 years ago
- Merge branch 'GH-18468' into v1.10.1-clang-windows — committed to arizvisa/golang by arizvisa 6 years ago
- Added a function to src/cmd/go/internal/work/exec.go that copies arguments into a response file if the total length of all the args is larger than the limitation imposed by windows. Also Modified runO... — committed to arizvisa/golang by arizvisa 6 years ago
- Merge branch 'GH-18468' into v1.10.2-clang-windows — committed to arizvisa/golang by arizvisa 6 years ago
- Merge branch 'GH-18468' into v1.10.2-clang-windows — committed to arizvisa/golang by arizvisa 6 years ago
- cmd/internal: added support for response files This adds support for parsing response files to all tools. This was done by re-implementing the buildargv func from gcc's libiberty/argv.c and then upd... — committed to arizvisa/golang by arizvisa 6 years ago
- cmd/go: on windows, if args are larger than limit then use response file This modifies golang's tools to check if the total number of arguments will result in a commandline larger than 32k. If we're ... — committed to arizvisa/golang by arizvisa 6 years ago
You could patch it in and recompile Go if it’s urgent.
But I suppose we could also backport it to Go 1.10.x if we do another one.
@gopherbot, please backport.
I’ve submitted 17fbb83693d5d4b880bb128d7afdb137840f76ec (https://go-review.googlesource.com/c/go/+/110395). @arizvisa, please double check that it works for you?
I at least made it such that when it runs on our build farm, 10% of the compile/link invocations go through this code path, so it will get some exercise even for non-large build arguments.
It would be nice to solve the general problem, but perhaps Windows does not provide a mechanism for that. If we can only solve the problem for cmd/go, then of course we should do that.
For the record, GCC and friends do this by treating any argument that starts with
'@'as a response file. The file is turned into a sequence of white-space separated strings, and the response file argument is replaced by the resulting set of arguments. This seems to be a standard Windows concept, documented at https://msdn.microsoft.com/en-us/library/windows/desktop/aa367156(v=vs.85).aspx .Got same issue with Golang 1.9.3
@kardianos. My plan was to teach
flagabout response files (as something you could opt into) and then optcmd/{go,compile}into supporting response files and change the part ofcmd/goto use a response file when invokingcmd/compileif the command would be too long otherwise.I’m happy to take whatever approach you all want, I just care about being able to build projects with lots of .go files in them on windows.
Note: #21145, just closed as a dup of this issue, has an handy Powershell script that creates a folder that triggers the problem.