Skip to content
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: -buildmode=c-shared not supported on windows/arm #43800

Open
TopperDEL opened this issue Jan 20, 2021 · 15 comments
Open

cmd/link: -buildmode=c-shared not supported on windows/arm #43800

TopperDEL opened this issue Jan 20, 2021 · 15 comments

Comments

@TopperDEL
Copy link

@TopperDEL TopperDEL commented Jan 20, 2021

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

$ go version 1.15.6

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vsts/.cache/go-build"
GOENV="/home/vsts/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/vsts/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vsts/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/hostedtoolcache/go/1.15.6/x64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/hostedtoolcache/go/1.15.6/x64/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build442356246=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I try to cross-compile a Go-library for windows/arm and windows/arm64 to P/Invoke it from .Net. Although Go states to support "windows/arm" as a build target this is not true for buildmode=c-shared.

What did you expect to see?

windows/arm being supported.

What did you see instead?

"-buildmode c-shared not supported for windows/arm"

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 20, 2021

CC @zx2c4

@dmitshur dmitshur added this to the Backlog milestone Jan 20, 2021
@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 4, 2021

Is there anything I could do? Might it already work just by adjusting the parameter check and let that combination "go through"?

If not: is there any ETA for this? I do not want to make pressure - it's just quite necessary for an app I'm currently building and it would at least be helpful to get a feeling about the complexity, if it should be possible or not and when it might be realistic that the feature will make it into Go.

This would bring Go to devices like the HoloLens 2 or a Surface X. I can't imagine that I'm the only one needing this. :)

Thank you!

@thanm
Copy link
Member

@thanm thanm commented Feb 4, 2021

I'm not aware of any specific issues blocking "-buildmode=c-shared" on windows/arm, maybe @cherrymui knows more. I think the main stumbling block is that we haven't had an owner for the port, nor have we a builder. You could certainly try commenting out the guard in the linker and see how things go.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 4, 2021

I think the main stumbling block is that we haven't had an owner for the port, nor have we a builder.

We do have a builder now, at least! (A “reverse” builder run by @zx2c4.)
https://github.com/golang/build/blob/6f0aa4e1ac923ee1f8249641d38ecb96db02a1e8/dashboard/builders.go#L2250-L2256

@thanm
Copy link
Member

@thanm thanm commented Feb 4, 2021

Ah, thanks.

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 4, 2021

I'm not that deep into Go and how builders work and help here - what needs to happen then to bring this further?
Thank you all for your help and quick response!

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 11, 2021

Sorry if I push here - what needs to be done to get further? There seems to be a builder available. Can someone bringt this topic further?

Thank you in advance!

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Feb 11, 2021

windows/arm port doesn't support cgo yet. I think we need to support cgo before adding support of c-shared build mode. Thanks.

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 12, 2021

Thanks @cherrymui for the reply. I'm sorry for asking again and again but what/who could do this? I need windows/arm64 with cgo very soon so if there is anything someone could do to bring this further, I would be very happy and thankful. :)

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 13, 2021

Change https://golang.org/cl/291630 mentions this issue: cmd/link: set SizeOfRawData filed in COFF files for .bss section

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 13, 2021

Change https://golang.org/cl/291630 mentions this issue: cmd/link: set SizeOfRawData field in COFF files for .bss section

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291632 mentions this issue: cmd/link: do not pass -Bsymbolic for PE DLLs

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291633 mentions this issue: cmd/link: set .ctors COFF section to writable and aligned to 8 bytes

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291633 mentions this issue: cmd/link: set .ctors COFF section to writable and aligned

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291635 mentions this issue: runtime/cgo: implement for windows/arm and windows/arm64

gopherbot pushed a commit that referenced this issue Feb 23, 2021
… .bss section

GCC and Clang both set the SizeOfRawData field rather than the
VirtualSize field for communicating the size of the .bss section. As a
consequence, LLD does not look at VirtualSize and collapses the .bss
section into whatever is around it, resulting in runtime crashes. This
commit changes the logic so that if the requested "file size" is 0, then
the SizeOfRawData field is set rather than the VirtualSize field as the
sole length marker.

Fixes #44250.
Fixes #39326.
Updates #38755.
Updates #36439.
Updates #43800.

Change-Id: Ied89ddaa0a717fed840238244c6e4848845aeeb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/291630
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
gopherbot pushed a commit that referenced this issue Feb 23, 2021
This is only a valid option on ELF. Binutils accepts it, but LLVM
rejects it, so for Windows, it's best to just omit it.

Updates #44250.
Updates #39326.
Updates #38755.
Updates #36439.
Updates #43800.

Change-Id: Iffd2345d757f23dd737e63bd464cd412527077c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/291632
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
gopherbot pushed a commit that referenced this issue Feb 23, 2021
Without setting these flags, LLVM's LLD ignores the .ctors section when
merging objects.

Updates #44250.
Updates #39326.
Updates #38755.
Updates #36439.
Updates #43800.

Change-Id: I8766104508f7acd832088a590ee7d68afa0d6065
Reviewed-on: https://go-review.googlesource.com/c/go/+/291633
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants