New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: Filepaths and importpaths are concatenated as-is, should FromSlash (can cause problems under Windows) #26917

Closed
Xjs opened this Issue Aug 10, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@Xjs

Xjs commented Aug 10, 2018

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.

Windows appears to be confused by a path that is relative, longer than 255 characters, AND a combination of backslashes and slashes. (Some more info here.)

A fix that worked for me locally would be to use the filepath functions in src/cmd/link/internal/ld/ld.go, e. g. like Xjs@a9738aa .

In experiments I have found that using an absolute GOROOT doesn't reproduce the error; I will suggest this workaround to the Bazel rules_go authors, too.

What version of Go are you using (go version)?

go version go1.10.3 windows/amd64

Does this issue reproduce with the latest release?

Last reproduced with a9dcbab .

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Aug 11, 2018

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

@Xjs

This comment has been minimized.

Xjs commented Aug 13, 2018

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.)

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Aug 14, 2018

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

@Xjs

This comment has been minimized.

Xjs commented Aug 14, 2018

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.

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Aug 14, 2018

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

@Xjs

This comment has been minimized.

Xjs commented Aug 16, 2018

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.

@gopherbot

This comment has been minimized.

gopherbot commented Dec 7, 2018

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

@gopherbot gopherbot closed this in 9555769 Dec 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment