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: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

Closed
bep opened this issue Aug 14, 2020 · 22 comments

Comments

@bep
Copy link
Contributor

@bep bep commented Aug 14, 2020

I have a Travis build that fails on Windows after upgrading to Go 1.15, see:

See: https://travis-ci.org/github/gohugoio/hugo/builds/717877247

Or more specific: https://travis-ci.org/github/gohugoio/hugo/jobs/717877253

x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large: 77173
@deadprogram
Copy link

@deadprogram deadprogram commented Aug 15, 2020

This looks like a case of needing the flag -buildmode=exe when building Go programs for Windows that use CGo. Seems linking Windows ASLR executables is what is not working.

@networkimprov
Copy link

@networkimprov networkimprov commented Aug 15, 2020

@gopherbot add OS-Windows

cc @alexbrainman

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Aug 15, 2020

I do not know what the problem is.

But go 1.15 now passes --dynamicbase and --high-entropy-va flags to gcc for ASLR support. Perhaps your failure is related. Maybe you need to update your Mingw.

You can disable new flags by passing -buildmode=exe to go command as @deadprogram suggested.

Alex

@networkimprov
Copy link

@networkimprov networkimprov commented Aug 16, 2020

A search for that error suggests that too many symbols are exported by a DLL. Is export the default when it doesn't need to be?

cc @zx2c4 @ianlancetaylor

@networkimprov
Copy link

@networkimprov networkimprov commented Aug 16, 2020

@bep, everything builds except commands.test -- what's different about it?

@dmitshur dmitshur added this to the Backlog milestone Aug 17, 2020
@dmitshur dmitshur changed the title x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large cmd/link: x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large Aug 17, 2020
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Aug 17, 2020

Also /cc @cherrymui @aclements per owners.

@dmitshur dmitshur changed the title cmd/link: x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 Aug 17, 2020
@bep
Copy link
Contributor Author

@bep bep commented Aug 18, 2020

@bep, everything builds except commands.test -- what's different about it?

Compared to the other test packages, it starts a HTTP server ... But the main package also does that.

Note that I got the build going with buildMode=exe.

chenbh added a commit to concourse/ci that referenced this issue Aug 24, 2020
Something about DLLs and too many symbols
golang/go#40795

Signed-off-by: Bohan Chen <bochen@pivotal.io>
gythialy added a commit to qlcchain/go-qlc that referenced this issue Sep 14, 2020
golang/go#40795

Signed-off-by: Goren G <yong.gu@qlink.mobi>
@hackf5
Copy link

@hackf5 hackf5 commented Sep 19, 2020

Just got the latest version and tried to build on windows with go version go1.15.2 windows/amd64

C:\dev\go\pkg\tool\windows_amd64\link.exe: running g++ failed: exit status 1
C:/dev/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: export ordinal too large: 77248
collect2.exe: error: ld returned 1 exit status

Adding -buildmode=exe fixes the issue, but it still doesn't work straight out of the box.

Hmm, seems like the problems are more serious than this because after building the exe doesn't do anything. Don't worry about it, I'll get the binaries.

@aclements
Copy link
Member

@aclements aclements commented Sep 21, 2020

@hackf5 , could you elaborate on what's not working with -buildmode=exe?

Also /cc @thanm @jeremyfaller

@nwoodmsft
Copy link

@nwoodmsft nwoodmsft commented Oct 14, 2020

Is there a solution for Windows go code which can't move to -buildmode=exe ? (e.g. code which is expected to compile to a .dll for other applications to then load/use).

It seems like it's very easy to hit the "Error: export ordinal too large" error when building with -buildmode=c-shared for Windows. I have some go code which only has one function marked with //export ....but looking at the resultant dll using dumpbin shows the dll is exporting thousands of symbols (the symbols relate to all of the other 3rd party golang packages which my code imports). Is that expected? It seems like the same issue described here but that issue has been open for a long time with no update.

Is there any way to work around this large number of exported symbols or to pass the equivalent of /bigobj to mingw to use during the c-shared compile?

@nwoodmsft
Copy link

@nwoodmsft nwoodmsft commented Oct 17, 2020

This thread has the workaround which worked for me and more details of the pending go fix for this issue: #30674 (comment)

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 22, 2020

Change https://golang.org/cl/264459 mentions this issue: cmd/link: avoid exporting all symbols on windows buildmode=pie

@dmitshur dmitshur modified the milestones: Backlog, Go1.16 Feb 11, 2021
artursouza pushed a commit to dapr/components-contrib that referenced this issue Feb 11, 2021
* Run K8s secret store tests

* Add workaround for golang/go#40795

* Add clarity to the hack
lesam added a commit to influxdata/influxdb that referenced this issue Mar 23, 2021
Closes: #21018

See golang/go#40795
lesam added a commit to influxdata/influxdb that referenced this issue Mar 23, 2021
Closes: #21018

See golang/go#40795
lesam added a commit to influxdata/influxdb that referenced this issue Mar 23, 2021
Closes: #21018

See golang/go#40795
@gopherbot
Copy link

@gopherbot gopherbot commented Mar 31, 2021

Change https://golang.org/cl/300692 mentions this issue: [release-branch.go1.15] cmd/link: avoid exporting all symbols on windows buildmode=pie

gopherbot pushed a commit that referenced this issue Mar 31, 2021
…ows buildmode=pie

Marking one functions with __declspec(dllexport) forces mingw to
create .reloc section without having to export all symbols.

See https://insights.sei.cmu.edu/cert/2018/08/when-aslr-is-not-really-aslr---the-case-of-incorrect-assumptions-and-bad-defaults.html for more info.

This change cuts 73kb of a "hello world" pie binary.

Updates #6853.
Updates #40795.
Fixes #43592.

Change-Id: I3cc57c3b64f61187550bc8751dfa085f106c8475
Reviewed-on: https://go-review.googlesource.com/c/go/+/264459
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/300692
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: David Chase <drchase@google.com>
ankitathomas added a commit to ankitathomas/operator-framework-olm that referenced this issue Apr 6, 2021
With golang 1.15.5, attempting the windows cross build fails with mingw
ld reporting "Error: export ordinal too large: 69634", which is:

golang/go#40795

The suggested workaround for executables is -buildmode=exe.

(upstream operator-registry commit: 116a5cc4355c1fb905c72a5f049c581f7e671623)
srenatus added a commit to srenatus/opa that referenced this issue Apr 28, 2021
Primarily for the windows build, but I don't think it should be wrong
for the others either:

golang/go#40795

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 28, 2021
Primarily for the windows build, but I don't think it should be wrong
for the others either:

golang/go#40795

See https://golang.org/cmd/go/#hdr-Build_modes:

> -buildmode=exe
> Build the listed main packages and everything they import into
> executables. Packages not named main are ignored.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 28, 2021
Primarily for the windows build, but I don't think it should be wrong
for the others either:

golang/go#40795

See https://golang.org/cmd/go/#hdr-Build_modes:

> -buildmode=exe
> Build the listed main packages and everything they import into
> executables. Packages not named main are ignored.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 29, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 29, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: bump to 1.16.3, keep compat with 1.15

  See https://golang.org/ref/mod#go-mod-file-go about the `go` directive in
  `go.mod`:

  > A go directive indicates that a module was written assuming the semantics
  > of a given version of Go.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 29, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: bump to 1.16.3, keep compat with 1.15

  See https://golang.org/ref/mod#go-mod-file-go about the `go` directive in
  `go.mod`:

  > A go directive indicates that a module was written assuming the semantics
  > of a given version of Go.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue Apr 30, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: bump to 1.16.3, keep compat with 1.15

  See https://golang.org/ref/mod#go-mod-file-go about the `go` directive in
  `go.mod`:

  > A go directive indicates that a module was written assuming the semantics
  > of a given version of Go.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue May 4, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: bump to 1.16.3, keep compat with 1.15

  See https://golang.org/ref/mod#go-mod-file-go about the `go` directive in
  `go.mod`:

  > A go directive indicates that a module was written assuming the semantics
  > of a given version of Go.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to srenatus/opa that referenced this issue May 5, 2021
Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: fix version as 1.16.3

  This was discussed in this PR, but not the other one. We'd rather keep
  this an exact match.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: replace build-docker by build-linux

  Turns out the binaries were identical now.

- workflow: adapt github workflows
- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit to open-policy-agent/opa that referenced this issue May 5, 2021
* build: WASM_ENABLED=1 for all platforms, bump go to 1.16.3

Notes:
- If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages
- We could build a builder image instead of installing the package every
  time.
- ci-go-*: run as root now, so we're able to install the packages for
  windows.
- tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

- build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  > -buildmode=exe
  > Build the listed main packages and everything they import into
  > executables. Packages not named main are ignored.

- go: fix version as 1.16.3 (not 1.16)

  We'd rather keep this an exact match.

- build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  > The go command now builds packages in module-aware mode by default.

  Also, since we've added the `go 1.15` directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  > At go 1.14 or higher, automatic vendoring may be enabled. If the file
  > vendor/modules.txt is present and consistent with go.mod, there is no
  > need to explicitly use the -mod=vendor flag.

- build: override docker id/gid in 'image' target, to keep existing
  behaviour.

* workflow: use binaries built before, remove workaround

split linux and windows to not wait for the windows build to finish
before starting the npm-opa-wasm tests.

* wasm-sdk: show where to get binaries, don't panic

Fixes #3264.

* Makefile: deprecate old targets, introduce new ones

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.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