cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

bep · 2020-08-14T13:58:10Z

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

The text was updated successfully, but these errors were encountered:

deadprogram · 2020-08-15T20:49:23Z

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 · 2020-08-15T23:07:38Z

@gopherbot add OS-Windows

cc @alexbrainman

alexbrainman · 2020-08-15T23:47:23Z

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 · 2020-08-16T00:13:35Z

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 · 2020-08-16T02:37:06Z

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

dmitshur · 2020-08-17T23:19:01Z

Also /cc @cherrymui @aclements per owners.

bep · 2020-08-18T11:54:04Z

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

Something about DLLs and too many symbols golang/go#40795 Signed-off-by: Bohan Chen <bochen@pivotal.io>

golang/go#40795 Signed-off-by: Goren G <yong.gu@qlink.mobi>

hackf5 · 2020-09-19T09:19:51Z

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 · 2020-09-21T16:56:35Z

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

Also /cc @thanm @jeremyfaller

nwoodmsft · 2020-10-14T13:26:41Z

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 · 2020-10-17T14:10:09Z

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

gopherbot · 2020-10-22T20:41:51Z

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

Closes: #21018 See golang/go#40795

gopherbot · 2021-03-31T19:46:48Z

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

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

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)

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>

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

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 · 2021-07-14T02:36:02Z

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

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

Applies a temporary fix similar to grafana/grafana#28557 before go 1.15.6+ fixes golang/go#40795

bep mentioned this issue Aug 14, 2020

Update to Go 1.15 gohugoio/hugo#7554

Closed

deadprogram mentioned this issue Aug 15, 2020

core: support for Go 1.15 tinygo-org/tinygo#1293

Merged

gopherbot added the OS-Windows label Aug 15, 2020

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 added this to the Backlog milestone Aug 17, 2020

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

chenbh added a commit to concourse/ci that referenced this issue Aug 24, 2020

fix go1.15 windows builds failing

3404168

Something about DLLs and too many symbols golang/go#40795 Signed-off-by: Bohan Chen <bochen@pivotal.io>

chenbh mentioned this issue Aug 24, 2020

fix go1.15 windows builds failing concourse/ci#373

Merged

ianlancetaylor mentioned this issue Aug 24, 2020

Changes between go1.14.7 and go1.15 increase the number of symbols on windows to be exported causing build to fail #41013

Closed

techknowlogick mentioned this issue Aug 24, 2020

go1.15 on windows go-gitea/gitea#12589

Merged

gythialy pushed a commit to qlcchain/go-qlc that referenced this issue Sep 14, 2020

chore: downgrade go builder version

81ce5e3

golang/go#40795 Signed-off-by: Goren G <yong.gu@qlink.mobi>

qmuntal mentioned this issue Sep 19, 2020

cmd/go: enable ASLR on Windows -buildmode=c-shared #41421

Closed

jay-sridharan mentioned this issue Sep 29, 2020

Unable to build rticommunity/telegraf on Windows rticommunity/telegraf#1

Closed

networkimprov mentioned this issue Oct 14, 2020

cmd/link: -buildmode=c-shared exports many functions, not just //export functions #30674

Closed

dunglas mentioned this issue Oct 20, 2020

ci: set up GitHub Actions. Add a test for x-smaxage caddyserver/cache-handler#7

Merged

aknuds1 mentioned this issue Oct 27, 2020

Fix backend build on Windows grafana/grafana#28557

Merged

gopherbot closed this as completed in e463c28 Nov 2, 2020

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

build: fix windows build for go1.15

c517d62

Closes: #21018 See golang/go#40795

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

build: fix windows build for go1.15 (#21041)

adee278

Closes: #21018 See golang/go#40795

GsssC mentioned this issue Mar 30, 2021

When I debug cloudcore moduler. This is the error infmation kubeedge/kubeedge#2746

Closed

github-actions bot mentioned this issue Apr 2, 2021

upstream reference closed: github.com/golang/go/issues/40795 ory/keto#522

Closed

1 task

mx-psi mentioned this issue Apr 13, 2021

[golang] Bump builder Golang version from 1.14 to 1.15 DataDog/datadog-agent-buildimages#126

Merged

sgnn7 mentioned this issue Apr 13, 2021

[build] Update CircleCI runner image to use Golang 1.15.11 DataDog/datadog-agent#7873

Merged

hanjm mentioned this issue Apr 18, 2021

Add pulsar exporter (#3164) open-telemetry/opentelemetry-collector-contrib#3165

Closed

srenatus mentioned this issue Apr 29, 2021

build: WASM_ENABLED=1 for all platforms open-policy-agent/opa#3416

Merged

negative0 pushed a commit to negative0/rclone that referenced this issue Aug 13, 2021

build: Temporary fix for Windows build errors

8416f97

Applies a temporary fix similar to grafana/grafana#28557 before go 1.15.6+ fixes golang/go#40795

gracewehner mentioned this issue Aug 19, 2021

upgrade golang version for windows in pipeline and locally microsoft/Docker-Provider#630

Merged

adamboutcher added a commit to statping-ng/statping-ng that referenced this issue Aug 20, 2021

Added a build flag for windows see golang/go#40795

62929e6

gakonst mentioned this issue Mar 17, 2022

compiling on windows gnu gakonst/ethers-rs#880

Open

golang locked and limited conversation to collaborators Jul 14, 2022

gopherbot added the FrozenDueToAge label Jul 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

bep commented Aug 14, 2020

deadprogram commented Aug 15, 2020

networkimprov commented Aug 15, 2020

alexbrainman commented Aug 15, 2020

networkimprov commented Aug 16, 2020 •

edited

Loading

networkimprov commented Aug 16, 2020

dmitshur commented Aug 17, 2020

bep commented Aug 18, 2020

hackf5 commented Sep 19, 2020 •

edited

Loading

aclements commented Sep 21, 2020

nwoodmsft commented Oct 14, 2020 •

edited

Loading

nwoodmsft commented Oct 17, 2020

gopherbot commented Oct 22, 2020

gopherbot commented Mar 31, 2021

lingluan533 commented Jul 14, 2021

cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 #40795

Comments

bep commented Aug 14, 2020

deadprogram commented Aug 15, 2020

networkimprov commented Aug 15, 2020

alexbrainman commented Aug 15, 2020

networkimprov commented Aug 16, 2020 • edited Loading

networkimprov commented Aug 16, 2020

dmitshur commented Aug 17, 2020

bep commented Aug 18, 2020

hackf5 commented Sep 19, 2020 • edited Loading

aclements commented Sep 21, 2020

nwoodmsft commented Oct 14, 2020 • edited Loading

nwoodmsft commented Oct 17, 2020

gopherbot commented Oct 22, 2020

gopherbot commented Mar 31, 2021

lingluan533 commented Jul 14, 2021

networkimprov commented Aug 16, 2020 •

edited

Loading

hackf5 commented Sep 19, 2020 •

edited

Loading

nwoodmsft commented Oct 14, 2020 •

edited

Loading