Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/cgo: removal of pre-built standard libraries results in compilation errors #58119

Closed
djedward opened this issue Jan 27, 2023 · 6 comments
Closed

cmd/cgo: removal of pre-built standard libraries results in compilation errors #58119

djedward opened this issue Jan 27, 2023 · 6 comments
Labels
FrozenDueToAge GoCommand cmd/go NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Backlog

Comments

@djedward
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.19.5 linux/amd64

Does this issue reproduce with the latest release?

Yes, go1.20rc3

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20rc3"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1278813214=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I introduced go1.20rc3 into our build system, which unfortunately still has some old Linux platforms we support.

What did you expect to see?

Builds to continue to function.

What did you see instead?

# runtime/cgo
cc1: warnings being treated as errors
_cgo_export.c:6: warning: ignoring #pragma GCC diagnostic
_cgo_export.c:7: warning: ignoring #pragma GCC diagnostic
_cgo_export.c:8: warning: ignoring #pragma GCC diagnostic

With our older Linux platforms, the change in 1.20rc* to remove the pre-built standard libraries has resulted in those platforms attempting to use cgo to compile net or similar packages. Since their default version of gcc is < 4.6, the builds now break on the diagnostic pragmas. I don't disagree with the removal of the pre-built libraries, it makes sense (and greatly reduced our internal distribution size). I'd like to discuss the possibility of modifying the CgoEnabled detection in cmd/go/internal/cfg to check that the gcc version meets the minimum requirements (even if CC is set). When it fails the min version check, it would default to disabling CGO (when CGO_ENABLED isn't set). We have a local patch to Go that I modeled off the compilerVersion() function in go/internal/work/init.go to accomplish this check. If that type of check seems reasonable, I could work on cleaning up our patch and submitting a PR.
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jan 27, 2023
@bcmills bcmills added GoCommand cmd/go and removed compiler/runtime Issues related to the Go compiler and/or runtime. labels Jan 27, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jan 27, 2023
@bcmills bcmills added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed compiler/runtime Issues related to the Go compiler and/or runtime. labels Jan 27, 2023
@bcmills bcmills added this to the Backlog milestone Jan 27, 2023
@bcmills
Copy link
Contributor

bcmills commented Jan 27, 2023

Since their default version of gcc is < 4.6, the builds now break on the diagnostic pragmas.

I don't like the idea of adding extra complexity (and potentially latency) to cmd/go for this case.

GCC 4.6 was released in March 2011 — over a decade ago! Is there some widely-used distro that is still actively supported by its distributor and still uses such an old compiler?

Even then, you should be able to set CGO_ENABLED=0 explicitly before building when needed — is there some reason that is not viable for your case?

(CC @ianlancetaylor)

@djedward
Copy link
Author

djedward commented Jan 27, 2023 •
edited

We have a rather large build system, so finding the right places to set CGO_ENABLED=0 where it fixes all the broken builds, but doesn't break others that are setting CGO_ENABLED=1 is difficult. And our Linux distribution is definitely old (and we've been "deprecating" it for a long time...). I can definitely see the hesitance in adding the check due to complexity/latency concerns (why I figured I'd feel it out before putting together a proper PR), especially given it probably isn't common for the average Go dev to run into this combination.

But I can see the argument that if cmd/go is deciding to use a gcc on your behalf (at least in the CC not set case, but on the path), it should be defaulting to the correct behavior. And the complexity currently does exist in work to verify the version for asan (though that clearly isn't the common path).

@bcmills
Copy link
Contributor

bcmills commented Jan 27, 2023

The complexity for asan builds should not affect simple commands like go env CGO_ENABLED, though.

(Do note that for custom build systems you may be able to set GODEBUG=installgoroot=all as another workaround.)

@ianlancetaylor
Copy link
Contributor

What C compiler are you using? GCC has supported #pragma GCC diagnostic since the 4.2 release in 2007.

Assuming you are using an earlier release, you could perhaps set CGO_CFLAGS=-Wno-unknown-pragmas to disable the error. That option was available in at least the 2.95 release in 1997.

@djedward
Copy link
Author

4.1 unfortunately :(. Thank you both for the suggestions. I can check and see if the CGO_CFLAGS will flow through without being overwritten in too many places. With flags, I'm just a little worried about them being overwritten by other systems in the future (I'm still waiting/working on that future where I don't have to try and keep things building on a linux distribution from 2006/7 😄...).

And overall, I don't disagree that this type of change could be a bit heavyweight for such a niche use-case, so feel free to close!

@ianlancetaylor
Copy link
Contributor

Currently on https://go.dev/wiki/MinimumRequirements we document that GCC 4.6 is required, so I think it's OK that we don't support GCC 4.1. Sorry.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Jan 27, 2023
@golang golang locked and limited conversation to collaborators Jan 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@ianlancetaylor @bcmills @djedward @gopherbot