Using Bazel and rules_go, a combination of factors leads to cmd/link being executed with a GOROOT relative to the build workspace folder, whose path can become very long. This resulted in obscure linker error messages such as:

external\go_sdk\pkg\tool\windows_amd64\link.exe: cannot open file bazel-out\x64_windows-fastbuild\bin\external\io_bazel_rules_go\windows_amd64_pure_stripped\stdlib%\pkg\windows_amd64/vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20.a: open bazel-out\x64_windows-fastbuild\bin\external\io_bazel_rules_go\windows_amd64_pure_stripped\stdlib%\pkg\windows_amd64/vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20.a: The system cannot find the path specified.

How do I reproduce your problem here? Please, provide small program and instructions to reproduce. Thank you.

Alex

Oh, I'm sorry, I meant to link to https://github.com/Xjs/go-link-path-concat-bug. (GOROOT will need to be replaced in the scripts if it is not C:\Go on your machine.)

https://github.com/Xjs/go-link-path-concat-bug

There might be other problems.

But

SET GOROOT=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\Go
C:\\Go\\pkg\\tool\\windows_amd64\\link.exe -o test.exe test.a

GOROOT has to be absolute path, not relative.

Also relative paths on Windows cannot be longer than 255 characters.

I still do not understand what your problem is. What exactly are you trying to do?

Alex

Actually, I'm trying a Bazel build under Windows. Bazel's rules_go set the GOROOT to a relative path. (I'm discussing this with the rules_go maintainers as well.) However, I tried to recreate this bug as-is. It would be a lot of overhead to recreate a Bazel build that exhibits this behaviour, so I tried to isolate it as much as possible. If you like, I can provide a Bazel example as well, of course.

My concrete bug report is that findlib (https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/ld.go#L106) constructs paths to object files by simply concatenating strings, one of which being the importpath that contains slashes. Under Windows, this results in a path like very\long\path/fmt which is not found because relative paths longer than 255 characters cannot have slashes as directory separator.

So I'm suggesting using the filepath functions in findlib in https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/ld.go#L106.

Actually, I'm trying a Bazel build under Windows.

Thank you for explaining.

Bazel's rules_go set the GOROOT to a relative path.

I am pretty sure, you cannot have GOROOT set to a relative path. But I will let others to confirm.

Under Windows, this results in a path like very\long\path/fmt which is not found because relative paths longer than 255 characters cannot have slashes as directory separator.

I do not believe any relative paths on Windows are allowed to be longer than 255 chars. So I don't see why expecting this to work.

Alex

Quoting from bazelbuild/rules_go#1664 (comment):

About the comment for GOROOT being an absolute path, it's required to be an absolute path by go build and go installl, which we only use to build the standard library. The compiler and linker don't read GOROOT, so its value doesn't matter for them. We must set GOROOT to a relative path when invoking the builders, since analysis code can't produce absolute paths (we don't know where actions will run at that point), but builders can absolutize it if needed.

My original issue with this is now solved on the bazel-side. I still think the filepath functions should be used for constructing file paths for the sake of correctness, but I have no urgency in this anymore.

Change https://golang.org/cl/153237 mentions this issue: cmd/link: use filepath.Join rather than d + "/" + f