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 · 23 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Milestone

Comments

@bep
Copy link
Contributor

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

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

@gopherbot add OS-Windows

cc @alexbrainman

@alexbrainman
Copy link
Member

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

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

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 17, 2020
@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

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 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 pushed 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 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

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

Also /cc @thanm @jeremyfaller

@nwoodmsft
Copy link

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

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

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

lesam added a commit to influxdata/influxdb that referenced this issue Mar 23, 2021
lesam added a commit to influxdata/influxdb that referenced this issue Mar 23, 2021
@gopherbot
Copy link

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 pushed 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 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>
benluddy pushed a commit to benluddy/operator-framework-olm that referenced this issue Jul 1, 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-repository: operator-registry
Upstream-commit: 116a5cc4355c1fb905c72a5f049c581f7e671623
@lingluan533
Copy link

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.

this can work, thank you

openshift-merge-robot pushed a commit to openshift/operator-framework-olm that referenced this issue Jul 14, 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-repository: operator-registry
Upstream-commit: 116a5cc4355c1fb905c72a5f049c581f7e671623
negative0 pushed a commit to negative0/rclone that referenced this issue Aug 13, 2021
Applies a temporary fix similar to grafana/grafana#28557
before go 1.15.6+ fixes golang/go#40795
adamboutcher added a commit to statping-ng/statping-ng that referenced this issue Aug 20, 2021
@golang golang locked and limited conversation to collaborators Jul 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Projects
None yet
Development

No branches or pull requests