[go] cmd/link: fallback to older minimum Windows target version on older C GNU toolchains
Quim Muntal (Gerrit)
Quim Muntal voted and added 1 comment![]( "Open in Gerrit")
Votes added by Quim Muntal
| Commit-Queue | +1 |
1 comment
This CL fixes many test failures in the standard library when using mingw-w64 14.2 or older.
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Quim Muntal (Gerrit)
Quim Muntal uploaded new patchset![]( "Open in Gerrit")
- TryBots-Pass: LUCI-TryBot-Result+1 by Go LUCI
Related details
- Alex Brainman
- Damien Neil
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Quim Muntal (Gerrit)
Quim Muntal voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Alex Brainman
- Damien Neil
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Jason Donenfeld (Gerrit)
Jason Donenfeld added 1 comment![]( "Open in Gerrit")
Could we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
Related details
- Alex Brainman
- Damien Neil
- Quim Muntal
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Quim Muntal (Gerrit)
Quim Muntal added 1 comment![]( "Open in Gerrit")
Could we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
I would love to do that, but the reality is that many Windows users use old mingw-w64 versions. I prefer to implement a small hack than to cause a widespread breakage.
Related details
- Alex Brainman
- Damien Neil
- Jason Donenfeld
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Jason Donenfeld (Gerrit)
Jason Donenfeld added 1 comment![]( "Open in Gerrit")
Quim MuntalCould we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
I would love to do that, but the reality is that many Windows users use old mingw-w64 versions. I prefer to implement a small hack than to cause a widespread breakage.
I sort of disagree on that approach, because of the nature of windows development; people aren't really tied to toolchains like they are with, e.g. supporting old Debian or whatever.
But if you do continue with this approach, I'd suggest you at least issue a nasty warning when going into the fallback path, mentioning that there's a behavior change and that this fallback won't last forever and so forth. There's got to be at least _something_ that moves us into the future.
Related details
- Alex Brainman
- Damien Neil
- Quim Muntal
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Quim Muntal (Gerrit)
Quim Muntal added 1 comment![]( "Open in Gerrit")
Quim MuntalCould we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
Jason DonenfeldI would love to do that, but the reality is that many Windows users use old mingw-w64 versions. I prefer to implement a small hack than to cause a widespread breakage.
I sort of disagree on that approach, because of the nature of windows development; people aren't really tied to toolchains like they are with, e.g. supporting old Debian or whatever.
But if you do continue with this approach, I'd suggest you at least issue a nasty warning when going into the fallback path, mentioning that there's a behavior change and that this fallback won't last forever and so forth. There's got to be at least _something_ that moves us into the future.
`_load_config_used` support was added to binutils in version 2.45, released on August 2025, which is less than one year old (see https://sourceware.org/pipermail/binutils/2025-April/140306.html). I wouldn't mind breaking (or printing nasty warnings) for +4 years old C toolchains, but it is not the case here.
There's got to be at least something that moves us into the future.
Agree, but let's separate this desire from fixing the compatibility issue.
Related details
- Alex Brainman
- Damien Neil
- Jason Donenfeld
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Jason Donenfeld (Gerrit)
Jason Donenfeld added 2 comments![]( "Open in Gerrit")
Quim MuntalCould we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
Jason DonenfeldI would love to do that, but the reality is that many Windows users use old mingw-w64 versions. I prefer to implement a small hack than to cause a widespread breakage.
Quim MuntalI sort of disagree on that approach, because of the nature of windows development; people aren't really tied to toolchains like they are with, e.g. supporting old Debian or whatever.
But if you do continue with this approach, I'd suggest you at least issue a nasty warning when going into the fallback path, mentioning that there's a behavior change and that this fallback won't last forever and so forth. There's got to be at least _something_ that moves us into the future.
`_load_config_used` support was added to binutils in version 2.45, released on August 2025, which is less than one year old (see https://sourceware.org/pipermail/binutils/2025-April/140306.html). I wouldn't mind breaking (or printing nasty warnings) for +4 years old C toolchains, but it is not the case here.
There's got to be at least something that moves us into the future.
Agree, but let's separate this desire from fixing the compatibility issue.
Agree, but let's separate this desire from fixing the compatibility issue.
So if you add this workaround, what I'm suggesting is: [see inline comments]
peMinorVersion = 1Print an ugly loud warning message here to stderr?
Related details
- Alex Brainman
- Damien Neil
- Quim Muntal
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Quim Muntal (Gerrit)
Quim Muntal added 2 comments![]( "Open in Gerrit")
Quim MuntalCould we instead just raise the minimum toolchain version on Windows to be binutils 2.45? I would actually like to impose a higher default MinGW version too, to get rid of hacks like this one: https://github.com/golang/go/blob/341b5e2c0261cc059b157f1c7a2a2c4d1f417f0d/src/runtime/cgo/gcc_libinit_windows.c#L18
That is to say, instead of adding hacks, what about just raising requirements? Toolchains on Windows are all ad-hoc anyway. Build systems just curl.exe in whatever they need.
Jason DonenfeldI would love to do that, but the reality is that many Windows users use old mingw-w64 versions. I prefer to implement a small hack than to cause a widespread breakage.
Quim MuntalI sort of disagree on that approach, because of the nature of windows development; people aren't really tied to toolchains like they are with, e.g. supporting old Debian or whatever.
But if you do continue with this approach, I'd suggest you at least issue a nasty warning when going into the fallback path, mentioning that there's a behavior change and that this fallback won't last forever and so forth. There's got to be at least _something_ that moves us into the future.
Jason Donenfeld`_load_config_used` support was added to binutils in version 2.45, released on August 2025, which is less than one year old (see https://sourceware.org/pipermail/binutils/2025-April/140306.html). I wouldn't mind breaking (or printing nasty warnings) for +4 years old C toolchains, but it is not the case here.
There's got to be at least something that moves us into the future.
Agree, but let's separate this desire from fixing the compatibility issue.
Agree, but let's separate this desire from fixing the compatibility issue.
So if you add this workaround, what I'm suggesting is: [see inline comments]
My point is that I don't want to add a warning for using a 1 year old C toolchain. That will break users expecting `go build` to finish without writing to stderr.
peMinorVersion = 1Print an ugly loud warning message here to stderr?
- Alex Brainman
- Damien Neil
- Jason Donenfeld
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Damien Neil (Gerrit)
Damien Neil voted and added 1 comment![]( "Open in Gerrit")
Votes added by Damien Neil
| Code-Review | +2 |
1 comment
(I like the idea of skipping the hacks and raising the minimum toolchain version, but I agree that requiring a toolchain that's only a year old is too soon.)
Related details
- Alex Brainman
- Jason Donenfeld
- Quim Muntal
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |