| 13 Sep 2025 |
 emily | (we probably also want to involve BuildModeSupported from just above to avoid defaulting to PIE on weird cross platforms I guess) | 19:30:17 |
| emily | we would definitely need to test though | 19:30:54 |
| emily | but I am reassured by the fact that it already has platforms that can do PIE but don't always do PIE | 19:31:02 |
| emily | for instance, Android is not in the list in ld/config.go | 19:31:20 |
| emily | it's just that aarch64-darwin doesn't support non-PIE at all | 19:31:32 |
| emily | https://github.com/search?q=repo%3Agolang%2Fgo%20DefaultPIE&type=code you can see the call sites of DefaultPIE here | 19:32:46 |
| emily | most relevantly https://github.com/golang/go/blob/ac803b5949f6dbc5bfa559afe506d35f9e1b3195/src/cmd/go/internal/work/init.go#L260-L267 which does tweak linking settings | 19:33:14 |
| emily | so I believe this is exactly the knob we want | 19:33:58 |
| emily | because it's handled in the higher-level go | 19:34:47 |
| emily | but I offer zero warranty for any of this, it definitely requires testing 😅 | 19:35:01 |
 Lun | diff --git a/src/internal/platform/supported.go b/src/internal/platform/supported.go
index f9706a6988..af301c7324 100644
--- a/src/internal/platform/supported.go
+++ b/src/internal/platform/supported.go
@@ -225,7 +225,6 @@ func InternalLinkPIESupported(goos, goarch string) bool {
switch goos + "/" + goarch {
case "android/arm64",
"darwin/amd64", "darwin/arm64",
- "linux/amd64", "linux/arm64", "linux/loong64", "linux/ppc64le",
"windows/386", "windows/amd64", "windows/arm", "windows/arm64":
return true
}
@@ -239,6 +238,8 @@ func DefaultPIE(goos, goarch string, isRace bool) bool {
switch goos {
case "android", "ios":
return true
+ case "linux":
+ return goarch != "ppc64"
case "windows":
if isRace {
// PIE is not supported with -race on windows;
Swapping the patch to this gets me default PIE binary requires external (cgo) linking, but cgo is not enabled in the go 1.25 build despite GO_EXTLINK_ENABLED=1 being set.
| 19:39:11 |
| emily | interesting | 19:39:51 |
| emily | is there anything around it in the log? | 19:39:56 |
| Lun | https://gist.github.com/LunNova/3c5e30929e8f914f7866d736966f00bc | 19:40:22 |
| emily | a bootstrap problem I suppose… | 19:40:48 |
| emily | https://github.com/golang/go/blob/ac803b5949f6dbc5bfa559afe506d35f9e1b3195/src/cmd/go/internal/load/pkg.go#L2643 | 19:41:32 |
| emily | there are, uh, no mentions of toolchain2 in the current Git? | 19:42:38 |
| emily | my guess is it can't find runtime/cgo in our bootstrap toolchain | 19:43:08 |
| emily | I wonder if perhaps the bootstrap toolchains need updating | 19:43:29 |
| emily | or maybe it can't handle the share/go in our bootstrap packages | 19:44:23 |
| emily | very much on the verge of being nerd-sniped here but trying to resist | 19:45:21 |
| Lun | your prior idea that you think is wrong now seemed to somewhat work and make pie binaries eg syncthing | 19:47:18 |
| emily | I think yeah because
- it wouldn't affect the bootstrap, only the built compiler, it seems like it bootstraps with the new
go command but the bootstrap toolchain (?)
- it forces the issue (there is no opt out) and just makes
-linkmode=internal silently produce FHS stuff
| 19:49:57 |
| emily | e.g. I wonder if the Go toolchain itself was a PIE for the old idea | 19:50:08 |
| emily | I am quite confident the old idea is wrong now though | 19:50:13 |
| emily | Lun: I think you may need to adjust src/cmd/dist/build.go too | 19:52:44 |
| emily | // mustLinkExternal is a copy of internal/platform.MustLinkExternal,
// duplicated here to avoid version skew in the MustLinkExternal function
// during bootstrapping.
| 19:52:51 |
| emily | kind of a mess | 19:53:00 |
| emily | in particular | 19:53:04 |
| emily | if !mustLinkExternal(goos, goarch, false) {
// Unless the platform requires external linking,
// we disable cgo to get static binaries for cmd/go and cmd/pprof,
// so that they work on systems without the same dynamic libraries
// as the original build system.
env = append(env, "CGO_ENABLED=0")
}
| 19:53:05 |
