ppc64le builds fail when resolving go deps (name mapping?)

[loosebazooka]

What version of rules_go are you using?

0.39.0

What version of Bazel are you using?

6.1.1

Does this issue reproduce with the latest releases of all the above?

yes

What operating system and processor architecture are you using?

linux, amd64

Any other potentially useful information about your toolchain?

no

What did you do?

built a simple go binary using arch ppc64le

WORKSPACE.bazel

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "6b65cb7917b4d1709f9410ffe00ecf3e160edf674b78c54a894471320862184f",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.39.0/rules_go-v0.39.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.39.0/rules_go-v0.39.0.zip",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.20.2")

BUILD

load("@io_bazel_rules_go//go:def.bzl", "go_binary")

go_binary(
    name = "hello",
    srcs = ["hello.go"],
    goarch = "ppc64le",
    goos = "linux",
    pure = "on",
)

hello.go

package main

import (
	"fmt"
)

func main() {
	fmt.Print("hi")
}

What did you expect to see?

It builds like any other architecture (this works with amd64, arm64, arm, s390x), but not ppc64le

What did you see instead?

hello.go:4:2: could not import fmt (open bazel-out/k8-fastbuild-ST-28dcfbc35f29/bin/external/io_bazel_rules_go/stdlib_/pkg/linux_ppc64le/fmt.a: no such file or directory)

It does not build, go dependencies are downloaded somewhere unexpected (pkg/linux_ppc64) instead of (pkg/linux_ppc64le).

One fix is to remove this line: https://github.com/bazelbuild/rules_go/blob/3125d8f0971bee56f069bbb33beb6686109fb71d/go/private/platforms.bzl#L34 but I assume that has some sort of side effect. I don't know enough bazel or go to debug any further yet.

[loosebazooka]

Perhaps this requires a new cpu type: bazelbuild/platforms#64 ?

[loosebazooka]

Best I could discern is that it looks like the map is overwriting values because two arches share a platform key?

[fmeum]

Yes, I think that without a dedicated platform constraint value for the CPU we can't solve this properly on the rules_go side.