Skip to content

update to go1.22.6#46982

Merged
thaJeztah merged 5 commits intomoby:masterfrom
thaJeztah:update_go_1.22
Sep 2, 2024
Merged

update to go1.22.6#46982
thaJeztah merged 5 commits intomoby:masterfrom
thaJeztah:update_go_1.22

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Dec 21, 2023 •
edited
Loading

@thaJeztah
Copy link
Member Author

thaJeztah commented Dec 21, 2023

Arf.. here we go again with pre-releases and the odd version format;

Setup go version spec 1.22rc1
Attempting to download 1.22rc1...
matching 1.22rc1...
Not found in manifest.  Falling back to download directly from Go
Error: Unable to find Go version '1.22rc1' for platform linux and architecture x64.

@thaJeztah thaJeztah force-pushed the update_go_1.22 branch 2 times, most recently from f04ee72 to 6edf610 Compare January 3, 2024 12:15
@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 3, 2024

Interesting; two failures: a panic in golang-ci-lint;

ERRO [runner] Panic: cgocall: package "sdjournal" (isInitialPkg: true, needAnalyzeSource: true): runtime error: invalid memory address or nil pointer dereference: goroutine 28078 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x5e
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*action).analyzeSafe.func1()
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_action.go:109 +0x277
panic({0x1647820?, 0x222b380?})
	/usr/local/go/src/runtime/panic.go:770 +0x132
go/types.(*Checker).handleBailout(0xc01126f200, 0xc0115d7a48)
	/usr/local/go/src/go/types/check.go:367 +0x88
panic({0x1647820?, 0x222b380?})
	/usr/local/go/src/runtime/panic.go:770 +0x132
go/types.(*StdSizes).Sizeof(0x0, {0x1a39980, 0x2243120})
	/usr/local/go/src/go/types/sizes.go:228 +0x31e
go/types.(*Config).sizeof(...)
	/usr/local/go/src/go/types/sizes.go:333
go/types.representableConst.func1({0x1a39980?, 0x2243120?})
	/usr/local/go/src/go/types/const.go:76 +0x9e
go/types.representableConst({0x1a3f448, 0x23844e0}, 0xc01126f200, 0x2243120, 0xc0115d4e80)
	/usr/local/go/src/go/types/const.go:92 +0x192
go/types.(*Checker).representation(0xc01126f200, 0xc0115dab40, 0x2243120)
	/usr/local/go/src/go/types/const.go:256 +0x65
go/types.(*Checker).implicitTypeAndValue(0xc01126f200, 0xc0115dab40, {0x1a399d0, 0xc00d21ef50})
	/usr/local/go/src/go/types/expr.go:375 +0x30d
go/types.(*Checker).assignment(0xc01126f200, 0xc0115dab40, {0x1a399d0, 0xc00d21ef50}, {0x181de26, 0x10})
	/usr/local/go/src/go/types/assignments.go:52 +0x2e5
go/types.(*Checker).initVar(0xc01126f200, 0xc0115b7500, 0xc0115dab40, {0x181de26, 0x10})
	/usr/local/go/src/go/types/assignments.go:163 +0x41e
go/types.(*Checker).initVars(0xc01126f200, {0xc011543d60, 0x2, 0x1a39980?}, {0xc011579800, 0x22430e0?, 0xc0115c15c0?}, {0x1a3d7f8, 0xc011579820})
	/usr/local/go/src/go/types/assignments.go:383 +0x638
go/types.(*Checker).stmt(0xc01126f200, 0x0, {0x1a3d7f8, 0xc011579820})
	/usr/local/go/src/go/types/stmt.go:524 +0x1fb7
go/types.(*Checker).stmtList(0xc01126f200, 0x0, {0xc011543010?, 0x17a002a?, 0x5?})
	/usr/local/go/src/go/types/stmt.go:121 +0x85
go/types.(*Checker).stmt(0xc01126f200, 0x0, {0x1a3d888, 0xc011576b10})
	/usr/local/go/src/go/types/stmt.go:562 +0x20e5
go/types.(*Checker).stmt(0xc01126f200, 0x0, {0x1a3d8b8, 0xc01157c280})
	/usr/local/go/src/go/types/stmt.go:574 +0x2ff7
go/types.(*Checker).stmtList(0xc01126f200, 0x0, {0xc01157c300?, 0x0?, 0x0?})
	/usr/local/go/src/go/types/stmt.go:121 +0x85
go/types.(*Checker).funcBody(0xc01126f200, 0x1a399d0?, {0x1a2b6d8?, 0xc000154000?}, 0xc0115a6e00, 0xc011576b40, {0x0?, 0x0?})
	/usr/local/go/src/go/types/stmt.go:41 +0x331
go/types.(*Checker).funcDecl.func1()
	/usr/local/go/src/go/types/decl.go:852 +0x3a
go/types.(*Checker).processDelayed(0xc01126f200, 0x0)
	/usr/local/go/src/go/types/check.go:467 +0x162
go/types.(*Checker).checkFiles(0xc01126f200, {0xc01152a4e8, 0x1, 0x1})
	/usr/local/go/src/go/types/check.go:411 +0x1cc
go/types.(*Checker).Files(...)
	/usr/local/go/src/go/types/check.go:372
go/types.(*Config).Check(0xc010bd76e0, {0xc001131950?, 0x5b?}, 0xc002085b40, {0xc01152a4e8, 0x1, 0x1}, 0xc010bd7740)
	/usr/local/go/src/go/types/api.go:458 +0x79
golang.org/x/tools/go/analysis/passes/cgocall.typeCheckCgoSourceFiles(0xc002085b40, 0xc00c93ce40, {0xc00d3072a0, 0x4, 0x4?}, 0xc00c93cea0, {0x1a3cdd8, 0x0})
	/go/pkg/mod/golang.org/x/[email protected]/go/analysis/passes/cgocall/cgocall.go:281 +0x3fc
golang.org/x/tools/go/analysis/passes/cgocall.run(0xc0111524e0)
	/go/pkg/mod/golang.org/x/[email protected]/go/analysis/passes/cgocall/cgocall.go:48 +0xb7
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*action).analyze(0xc004dee080)
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_action.go:195 +0x99a
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*action).analyzeSafe.func2()
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_action.go:113 +0x17
github.com/golangci/golangci-lint/pkg/timeutils.(*Stopwatch).TrackStage(0xc0016b0b90, {0x17a5ea9, 0x7}, 0xc00690ff48)
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/timeutils/stopwatch.go:111 +0x44
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*action).analyzeSafe(0xc002c89c20?)
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_action.go:112 +0x7a
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*loadingPackage).analyze.func2(0xc004dee080)
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_loadingpackage.go:80 +0xa8
created by github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*loadingPackage).analyze in goroutine 958
	/go/pkg/mod/github.com/golangci/[email protected]/pkg/golinters/goanalysis/runner_loadingpackage.go:75 +0x205

One in cross/linux/armv5 (so 32-bit cross-compile);

#55 [build 6/6] RUN --mount=type=bind,target=.,rw     --mount=type=tmpfs,target=cli/winresources/dockerd     --mount=type=tmpfs,target=cli/winresources/docker-proxy     --mount=type=cache,target=/root/.cache/go-build,id=moby-build-linux/arm/v5 <<EOT (set -e...)
#55 72.09 + rm -f /go/src/github.com/docker/docker/go.mod
#55 ERROR: process "/bin/sh -c   set -e\n  target=$([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"binary\" || echo \"dynbinary\")\n  xx-go --wrap\n  PKG_CONFIG=$(xx-go env PKG_CONFIG) ./hack/make.sh $target\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/dockerd$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/docker-proxy$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  mkdir /build\n  mv /tmp/bundles/${target}-daemon/* /build/\n" did not complete successfully: exit code: 1
------
 > [build 6/6] RUN --mount=type=bind,target=.,rw     --mount=type=tmpfs,target=cli/winresources/dockerd     --mount=type=tmpfs,target=cli/winresources/docker-proxy     --mount=type=cache,target=/root/.cache/go-build,id=moby-build-linux/arm/v5 <<EOT (set -e...):
0.796 + trap 'rm -f "${ROOTDIR}/go.mod"' EXIT
0.796 + GO111MODULE=on
0.796 + go build -mod=vendor -modfile=vendor.mod -o /tmp/bundles/binary-daemon/dockerd -tags 'netgo osusergo static_build  journald' -ldflags '-w -X "github.com/docker/docker/dockerversion.Version=dev" -X "github.com/docker/docker/dockerversion.GitCommit=HEAD" -X "github.com/docker/docker/dockerversion.BuildTime=2024-01-03T12:18:00.000000000+00:00" -X "github.com/docker/docker/dockerversion.PlatformName=" -X "github.com/docker/docker/dockerversion.ProductName=" -X "github.com/docker/docker/dockerversion.DefaultProductLicense="  -extldflags -static ' -gcflags= github.com/docker/docker/cmd/dockerd
5.968 # runtime/cgo
5.968 gcc_libinit.c:44:8: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
5.968 gcc_libinit.c:47:6: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
5.968 gcc_libinit.c:49:10: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
5.968 gcc_libinit.c:69:9: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
5.968 gcc_libinit.c:71:3: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
72.09 + rm -f /go/src/github.com/docker/docker/go.mod

@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 3, 2024

I noticed we were still on golangci-lint v1.54, so opened a PR to update to v1.55 (in case that fixes the panic); #47016

@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 3, 2024 •
edited
Loading

Ah; the good news; golangci-lint panic seems to be fixed.

The bad news; looks like Windows is pretty much broken;

failed to register layer: re-exec error: exit status 1: output: SetFileInformationByHandle \\?\C:\Windows\SystemTemp\hcs2001018820\Files.$wcidirs$: Invalid access to memory location.
Error: Process completed with exit code 1.

That codepath seems to be hit by go-winio;

moby/vendor/github.com/Microsoft/go-winio/fileinfo.go

Lines 21 to 34 in 7ad5396

// GetFileBasicInfo retrieves times and attributes for a file.
func GetFileBasicInfo(f *os.File) (*FileBasicInfo, error) {
bi := &FileBasicInfo{}
if err := windows.GetFileInformationByHandleEx(
windows.Handle(f.Fd()),
windows.FileBasicInfo,
(*byte)(unsafe.Pointer(bi)),
uint32(unsafe.Sizeof(*bi)),
); err != nil {
return nil, &os.PathError{Op: "GetFileInformationByHandleEx", Path: f.Name(), Err: err}
}
runtime.KeepAlive(f)
return bi, nil
}

And used by hcsshim;

git grep '\.SetFileBasicInfo'
vendor/github.com/Microsoft/hcsshim/internal/safefile/safeopen.go:      return winio.SetFileBasicInfo(f, &sbi)
vendor/github.com/Microsoft/hcsshim/internal/wclayer/baselayerwriter.go:                err = winio.SetFileBasicInfo(f, &di.fileInfo)
vendor/github.com/Microsoft/hcsshim/internal/wclayer/baselayerwriter.go:        err = winio.SetFileBasicInfo(f, fileInfo)
vendor/github.com/Microsoft/hcsshim/internal/wclayer/legacy.go: err = winio.SetFileBasicInfo(dest, fileInfo)
vendor/github.com/Microsoft/hcsshim/internal/wclayer/legacy.go:         err = winio.SetFileBasicInfo(f, fileInfo)
vendor/github.com/Microsoft/hcsshim/internal/wclayer/legacy.go: err = winio.SetFileBasicInfo(f, &strippedFi)

@dagood dagood mentioned this pull request Jan 3, 2024
Closed
@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 3, 2024

Friends at Microsoft are looking into this; tracking issue on their Go fork is here;

This was referenced Jan 11, 2024
Closed
Closed
@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 13, 2024

Looks like it's am in go-winio after all, and an alignment issue;

@dagood
Copy link

dagood commented Jan 16, 2024

The go-winio fix is merged: microsoft/go-winio#312, github.com/Microsoft/go-winio@008bc6ea43

@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 17, 2024

Thanks! I rebased, and updated go-winio to current master to see if CI is happier 🤞

@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 18, 2024

CI looks a lot happier now!

The only failure is cross-compile for linux/arm/v5. But looking at some output... interestingly it also shows alignment issues?

> [build 6/6] RUN --mount=type=bind,target=.,rw     --mount=type=tmpfs,target=cli/winresources/dockerd     --mount=type=tmpfs,target=cli/winresources/docker-proxy     --mount=type=cache,target=/root/.cache/go-build,id=moby-build-linux/arm/v5 <<EOT (set -e...):
0.786 + trap 'rm -f "${ROOTDIR}/go.mod"' EXIT
0.786 + GO111MODULE=on
0.786 + go build -mod=vendor -modfile=vendor.mod -o /tmp/bundles/binary-daemon/dockerd -tags 'netgo osusergo static_build  journald' -ldflags '-w -X "github.com/docker/docker/dockerversion.Version=dev" -X "github.com/docker/docker/dockerversion.GitCommit=HEAD" -X "github.com/docker/docker/dockerversion.BuildTime=2024-01-17T13:52:01.000000000+00:00" -X "github.com/docker/docker/dockerversion.PlatformName=" -X "github.com/docker/docker/dockerversion.ProductName=" -X "github.com/docker/docker/dockerversion.DefaultProductLicense="  -extldflags -static ' -gcflags= github.com/docker/docker/cmd/dockerd
7.003 # runtime/cgo
7.003 gcc_libinit.c:44:8: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
7.003 gcc_libinit.c:47:6: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
7.003 gcc_libinit.c:49:10: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
7.003 gcc_libinit.c:69:9: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
7.003 gcc_libinit.c:71:3: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Werror,-Watomic-alignment]
74.43 + rm -f /go/src/github.com/docker/docker/go.mod
------
Dockerfile:610
--------------------
 609 |     EOT
 610 | >>> RUN --mount=type=bind,target=.,rw \
 611 | >>>     --mount=type=tmpfs,target=cli/winresources/dockerd \
 612 | >>>     --mount=type=tmpfs,target=cli/winresources/docker-proxy \
 613 | >>>     --mount=type=cache,target=/root/.cache/go-build,id=moby-build-$TARGETPLATFORM <<EOT
 614 | >>>   set -e
 615 | >>>   target=$([ "$DOCKER_STATIC" = "1" ] && echo "binary" || echo "dynbinary")
 616 | >>>   xx-go --wrap
 617 | >>>   PKG_CONFIG=$(xx-go env PKG_CONFIG) ./hack/make.sh $target
 618 | >>>   xx-verify $([ "$DOCKER_STATIC" = "1" ] && echo "--static") /tmp/bundles/${target}-daemon/dockerd$([ "$(xx-info os)" = "windows" ] && echo ".exe")
 619 | >>>   xx-verify $([ "$DOCKER_STATIC" = "1" ] && echo "--static") /tmp/bundles/${target}-daemon/docker-proxy$([ "$(xx-info os)" = "windows" ] && echo ".exe")
 620 | >>>   mkdir /build
 621 | >>>   mv /tmp/bundles/${target}-daemon/* /build/
 622 | >>> EOT
 623 |     
--------------------
ERROR: failed to solve: process "/bin/sh -c   set -e\n  target=$([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"binary\" || echo \"dynbinary\")\n  xx-go --wrap\n  PKG_CONFIG=$(xx-go env PKG_CONFIG) ./hack/make.sh $target\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/dockerd$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/docker-proxy$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  mkdir /build\n  mv /tmp/bundles/${target}-daemon/* /build/\n" did not complete successfully: exit code: 1
Error: buildx bake failed with: ERROR: failed to solve: process "/bin/sh -c   set -e\n  target=$([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"binary\" || echo \"dynbinary\")\n  xx-go --wrap\n  PKG_CONFIG=$(xx-go env PKG_CONFIG) ./hack/make.sh $target\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/dockerd$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  xx-verify $([ \"$DOCKER_STATIC\" = \"1\" ] && echo \"--static\") /tmp/bundles/${target}-daemon/docker-proxy$([ \"$(xx-info os)\" = \"windows\" ] && echo \".exe\")\n  mkdir /build\n  mv /tmp/bundles/${target}-daemon/* /build/\n" did not complete successfully: exit code: 1

That appears seems to come from CLANG; https://github.com/c2lang/c2compiler/blob/82a0cc5a79860cba8555cd6ee95d278f34a8ecce/c2c/Clang/DiagnosticSemaKinds.inc#L2764 And that message also mentions "alignment", so now wondering if things are related to the issue we saw on Windows :thinking_face:

DIAG(warn_atomic_op_misaligned, CLASS_WARNING, (unsigned)diag::Severity::Warning, "misaligned or large atomic operation may incur significant performance penalty", 41, SFINAE_Suppress, false, false, 2)

A quick search also gave me some code-bases having exceptions for this; https://github.com/kokkos/kokkos/blob/71a9bcae52543bd065522bf3e41b5bfa467d8015/tpls/desul/include/desul/atomics/Compare_Exchange_GCC.hpp#L33-L41

// clang-format off
// Disable warning for large atomics on clang 7 and up (checked with godbolt)
// error: large atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment]
// https://godbolt.org/z/G7YhqhbG6
// clang-format on
#if defined(__clang__) && (__clang_major__ >= 7) && !defined(__APPLE__)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Watomic-alignment"
#endif

https://github.com/AaronRobinsonMSFT/DNNE/blob/3e39b7ca22dea40c4346be7e94810248ab402b38/src/platform/platform.c#L291-L297

#ifdef __clang__
#pragma clang diagnostic push
#ifdef __arm__
// warning: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes)
#pragma clang diagnostic ignored "-Watomic-alignment"
#endif // __arm__
#endif // __clang__

@dagood
Copy link

dagood commented Jan 24, 2024 •
edited
Loading

gcc_libinit.c:44

I checked for changes from go1.21.5 -> go1.22rc1, and all the lines with these warnings are actually new to 1.22: golang/go@b104a0e, golang/go#60961.

I don't know off the top of my head if ignoring the warnings is something that can be done in the code here, or whether that would mask some actually-bad effect here. (Worse startup time, if anything?) Seems worth raising upstream.

@corhere corhere mentioned this pull request Jan 25, 2024
Closed
@corhere
Copy link
Contributor

corhere commented Jan 25, 2024

Only clang is affected; cross-compiling with gcc works fine.

@thaJeztah
Copy link
Member Author

thaJeztah commented Jan 25, 2024

Thanks Cory!

I'll do a rebase of this one, and update to rc2 as well.

This was referenced Feb 8, 2024
Merged
Closed
@thaJeztah thaJeztah changed the title update to go1.22 update to go1.22.1 Mar 8, 2024
@thaJeztah
Copy link
Member Author

thaJeztah commented Mar 8, 2024

updated to go1.22.1

we don't have a tagged go-winio release with the patch yet though

@thaJeztah thaJeztah changed the title update to go1.22.1 update to go1.22.2 Apr 22, 2024
@thaJeztah thaJeztah deleted the update_go_1.22 branch September 2, 2024 16:23
thaJeztah added a commit to thaJeztah/docker that referenced this pull request Sep 2, 2024
@corhere @thaJeztah
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
442462a 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah thaJeztah mentioned this pull request Sep 2, 2024
Merged
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
311fd31 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
@austinvazquez austinvazquez mentioned this pull request Sep 3, 2024
Closed
@thaJeztah thaJeztah mentioned this pull request Sep 3, 2024
Merged
1 task
@vvoland vvoland mentioned this pull request Sep 3, 2024
Merged
1 task
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
48ae753 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
@austinvazquez austinvazquez mentioned this pull request Sep 3, 2024
Merged
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
524a401 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
@austinvazquez austinvazquez mentioned this pull request Sep 3, 2024
Merged
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
ba4525c 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
8c9984e 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
676a374 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
corhere added a commit to corhere/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
5d3fbce 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Cory Snider <[email protected]>
@corhere corhere mentioned this pull request Sep 3, 2024
Merged
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 3, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
86e1014 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 4, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
a45b4fd 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 4, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
23af4b7 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 4, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
b097b8c 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
austinvazquez pushed a commit to austinvazquez/moby that referenced this pull request Sep 4, 2024
@corhere @thaJeztah @austinvazquez
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
1f3742b 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit 4cd5c2b)
Signed-off-by: Austin Vazquez <[email protected]>
maggie44 pushed a commit to maggie44/moby that referenced this pull request Dec 8, 2024
@corhere @thaJeztah @maggie44
hack/make/.binary: set CGO_LDFLAGS=-latomic for arm/v5
bfc5ee1 
cross-compiling for arm/v5 was failing;

    moby#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced 2 more times
    moby#56 84.12
    moby#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
    moby#56 84.12 >>> referenced by gcc_libinit.c
    moby#56 84.12 >>>               /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
    moby#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)

From discussion on GitHub;
moby#46982 (comment)

The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.

In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.

While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.

Co-authored-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Cory Snider <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@corhere corhere corhere approved these changes

@vvoland vvoland vvoland approved these changes

@austinvazquez austinvazquez austinvazquez approved these changes

@tianon tianon Awaiting requested review from tianon tianon is a code owner

Assignees

@thaJeztah thaJeztah

Labels

area/packaging impact/changelog process/cherry-picked status/2-code-review

Projects

None yet

Milestone

28.0.0

Development

Successfully merging this pull request may close these issues.

5 participants

@thaJeztah @dagood @corhere @vvoland @austinvazquez