cmd/go: build: add -static flag

Question

cmd/go: build: add -static flag

kolyshkin opened this issue 6 years ago · 36 comments

This is a proposal to add -static flag to go build.

Producing a static build with go already requires a non-trivial amount of flags passed to go build, which on Linux currently amounts to something like:

-ldflags '-extldflags "-fno-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' [1]

...and this magic string keeps growing.

It would be awesome to encapsulate this sacred knowledge internally, exposing it via a new -static flag for go build and friends.

In addition to the above benefit of hiding the complexity, -static can also bring us more niceties, such as:

automatic static build tag third-party software can rely upon. Currently using static_build tag seems like a de-facto standard, used a lot, but it has to be explicitly defined like in [1] above.
providing --static flag to pkg-config invocations (those initiated by // #cgo pkg-config: lib lines in the source code). It will solve another issue (linking against a proper set of libraries for both static and dynamic link cases) for which a somewhat verbose workaround is currently required (for example, see ploop_link_static.go and ploop_link_dynamic.go).

The idea (specifically, the first part of it) is to hide the burden of choosing the build flags required in order to obtain a working static binary (on a best effort/knowledge basis). The above example is particularly valid for Linux/glibc. In case of Linux/musl (i.e. Alpine), for example, there is probably no need to use osusergo or netgo tags.

Answer 5 · 2018-07-24T14:59:18.000Z

Any chance you elaborate on what a static build does differently than regular build?

I would like to work on this proposal but I need further clarification.

Answer 6 · 2018-07-25T06:39:48.000Z

Any chance you elaborate on what a static build does differently than regular build?

It should

Set the needed build options (this is platform-dependent, Linux/glibc example is above).
Set the needed build tags (for Linux/glibc this currently amounts to osusergo netgo).
Set the static build tag.
Add the --static flag to pkg-config invocations (those triggered by // #cgo pkg-config: <lib> ... lines in the source code)

Answer 7 · 2018-08-03T05:35:21.000Z

Can I work on this as my first contribution to go?

Answer 8 · 2018-08-03T13:37:48.000Z

@vikramcse The main requirements here are access to a range of different systems in order to test the work, and the knowledge required to write a good test for whether the program is statically linked. The actual patch is probably not too difficult, I hope. If you still want to give this a try, please go ahead.

Answer 9 · 2018-08-04T06:07:16.000Z

Thanks @ianlancetaylor, I should start from simpler issue

Answer 10 · 2018-11-02T18:04:00.000Z

We build golang binaries across a variety of platforms, preferring static builds wherever possible. Here are the flags we're currently using:

windows: -tags netgo -ldflags '-H=windowsgui -extldflags "-static"'
linux/bsd: -tags netgo -ldflags '-extldflags "-static"'
macos: -ldflags '-s -extldflags "-sectcreate __TEXT __info_plist Info.plist"'
android: -ldflags -s

On macos and android, we need to be able to pull in system frameworks and libraries so we opted not to build static binaries.

Answer 11 · 2018-11-06T00:48:24.000Z

@tmm1 thanks for the info! Just noticed you should also use osusergo tag, at least for Linux.

Answer 12 · 2019-06-09T23:34:52.000Z

Unfortunately we didn't get to this during the Go1.13 cycle and currently we are in a code freeze so I shall punt this to Go1.14 and apply an Early-In-Cycle tag too.

Answer 13 · 2019-08-27T23:53:19.000Z

I think this won't work on macOS, where fully static builds are not allowed/supported by Apple. Binaries should always go through libSystem, which is also why we changed the way Go calls the kernel in Go 1.12. So, pure Go binaries are already as static as they can be, as far as I can tell.

I propose that on macOS go build -static simply tries to statically link cgo libraries, so that the final binary doesn't depend on third-party .so but just on system libraries. To do this, unfortunately, it looks like it's not sufficient to add the output of pkg-config --static --libs to LDFLAGS because that output still refers to each library as -L/path/to -lfoo (as this is the correct syntax when --static is passed to the linker, which we are not going to do in macOS). So, the output of pkg-config should be rewritten as /path/to/libfoo.a (using a similar library path search algorithm that the linker does).

Answer 14 · 2020-01-04T01:43:01.000Z

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o test -ldflags '-extldflags "-f no-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' test.go

...this is ridiculous

Answer 15 · 2020-01-04T01:57:21.000Z

@ddevault that's the point of the issue. I'm sure it can be done for 1.15 if someone steps up to do the work. I imagine the trickiest bit will be portability and writing good tests.

Answer 16 · 2020-01-16T17:44:26.000Z

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o test -ldflags '-extldflags "-f no-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' test.go

@ddevault How are you managing to combine CGO_ENABLED=0 and -buildmode pie? I get the error loadinternal: cannot find runtime/cgo, and from what I'm reading elsewhere it seems that buildmode pie is incompatible with disabling cgo? I'm just looking for the smallest static binary I can get, without cgo. If I remove -buildmode pie, it works... but I'm not sure if I should also be removing the -fno-PIC flag as well?

Answer 17 · 2020-01-16T17:46:22.000Z

loadinternal: cannot find runtime/cgo, as I understand it, is a red herring. I get this when compiling all Go projects under any configuration.

Answer 18 · 2020-01-16T18:18:44.000Z

Trying to run the binary generated after getting that warning gives me in instant death from a SIGTRAP. Guess I need to choose between -buildmode pie and CGO_ENABLED=0.

Answer 19 · 2020-05-01T15:16:08.000Z

[...] In case of Linux/musl (i.e. Alpine), for example, there is probably no need to use osusergo or netgo tags.

For completeness, in #38789 I discovered that osusergo is still necessary on Alpine Linux in some cases.

Answer 20 · 2020-05-28T19:57:04.000Z

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o test -ldflags '-extldflags "-f no-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' test.go

...this is ridiculous

This was sufficient for me to get a statically-linked binary for which readelf -d reports no linkage:

GOOS=linux go build -tags 'osusergo netgo'

Runs fine on CentOS when using CentOS, Alpine Linux, macOS, or Windows as the build OS.

Answer 21 · 2020-10-02T13:53:01.000Z

I'm just mentioning this here in case it helps anyone else with manually configured static builds: when we upgraded to go 1.15, I had to also add -linkmode=external to what we were passing to -ldflags, as mentioned in the 1.15 release notes in the linker section: https://golang.org/doc/go1.15#linker

In our case, we are building static binaries on Debian, to be run on Alpine. Without providing -linkmode=external, attempting to run those applications on Alpine resulted in the obscure error message standard_init_linux.go:211: exec user process caused "no such file or directory". Running file against those binaries noted that they were dynamically linked.

Answer 22 · 2020-10-02T13:56:07.000Z

@mark-rushakoff ahh nice! You just solved a sleepless night. :-)

Answer 23 · 2020-10-02T20:33:19.000Z

@zrhoffman: This was sufficient for me to get a statically-linked binary for which readelf -d reports no linkage:
GOOS=linux go build -tags 'osusergo netgo'

Do you happen to know whether this only works for Go projects using specific packages, or if it can be relied upon to generate static builds in all cases? I understand the latter is probably too much to hope for considering the length of this thread. :)

EDIT: To answer my own question, no, those build tags alone are not sufficient to produce a working static binary in all cases. CGO appears to make things much more complicated.

Answer 24 · 2021-03-12T21:35:01.000Z

Since nobody has mentioned GOFLAGS yet...

I was updating our script that effectively runs:

readonly GO_LDFLAGS='-linkmode=external -extldflags "-fno-PIC -static -Wl,-z,stack-size=8388608" -buildid='
readonly GO_STATICTAGS='osusergo netgo static_build'

go build -ldflags "${GO_LDFLAGS}" -buildmode pie -tags "${GO_STATICTAGS}" "$@"

because it was hardcoded to go build and now we need to use those flags for go test -c.

I thought I would be smart and just pack everything into GOFLAGS so that the script condenses to roughly

export GOFLAGS=...
go "$@"

and callers could use static-go.sh build ./my/pkg or static-go.sh test -c ./my/pkg. But then I ran into #26849, and I could not get around the GOFLAGS parsing errors because the -ldflags arguments are space-separated.

Being able to specify GOFLAGS=-static would have saved me a few hours today.

Answer 25 · 2021-03-23T08:24:10.000Z

How does -fno-PIC work with -buildmode pie ? Shouldn't it be -fPIC instead?

Answer 26 · 2021-05-10T17:57:53.000Z

To get a statically linked PIE executable I needed the following invocation (I'm mentioning this here, as I found this documented nowhere on the net, scraped it together from this thread, and this stackoverflow answer)

CGO_ENABLED=1 go build -buildmode=pie -tags 'osusergo,netgo,static,' -ldflags '-linkmode=external -extldflags "-static-pie"' .

The proposed -static flag would need to handle this case, when -buildmode=pie is also present.

Answer 27 · 2022-06-25T09:03:51.000Z

Have we supported fully statically linked goland compilation? for windows and linux.

Answer 28 · 2022-06-25T09:15:54.000Z

using this, can compile a golang executable program fully statically linked:

CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'

check for it:

# go build -a
# file apn-agent
apn-agent: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=fAb2KBW7w5qeGrLLkiea/-px5uehz18Quepc894yh/s88LK5dX_xAZ74PJYOsn/E9iJJiFDsEM5cYp1Pa2A, not stripped
# ldd apn-agent
        linux-vdso.so.1 (0x00007fff4c1fd000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f43b628e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f43b609c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f43b62c8000)
# ll | grep apn
-rwxr-xr-x 1 root root 15116026 Jun 25 17:15 apn-agent*

and check this:

# CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'
# file apn-agent
apn-agent: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=l7zmOUOlD2v6JDSmpqhh/MOFL-asmcrYcPwu074Mm/PXjsfd_J1bVSgy2-7EWd/NbMji1_HVCcDbqvKF6ho, not stripped
# ldd apn-agent
        not a dynamic executable
# ll | grep apn
-rwxr-xr-x 1 root root 15056583 Jun 25 17:13 apn-agent*

The statically linked one have smaller size, interesting :)

Answer 29 · 2022-06-27T08:30:41.000Z

Since this has been dragging on for a couple of years already, would it not be a better solution to include the instructions for static builds in the release notes for each version, since they keep on changing over time ? That would obviate the need for an actual code change.

Answer 30 · 2022-06-27T08:40:02.000Z

I think we could update the list at the top of this thread continuously for that purpose. Also, this doesn't make go build -static unnecessary, because you don't want everyone to have to carry a long command and keep it up to date.

@MaoJianwei we understand Go does support static builds - this thread is about making them easier to achieve.

Answer 31 · 2022-06-27T09:34:24.000Z

@MaoJianwei we understand Go does support static builds - this thread is about making them easier to achieve.

And hopefully less confusing, too: Often, static linking is used to make it easier to move binaries between different systems (of the same architecture), but that doesn't really work with glibc: there, dynamically linked binaries are compatible with glibc updates, but any glibc change (including certain minor version updates) may break statically linked binaries that use NSS or other forms of dlopen. So static linking for portability only works if CGO is disabled on the Go side and glibc does not enter the picture.

Answer 32 · 2022-06-27T11:57:50.000Z

@mvdan that's a start. The bonus if doing it in release notes is that each version could have relevant info, while this thread would likely be evergreen, only for the latest/next (which one ?) version. Or maybe a table per version here ?

Answer 33 · 2022-06-27T12:03:43.000Z

We did static builds with CGO enabled, it's not an problem if done right
Static builds allow using scratch docker images which dramatically reduces its size

Answer 34 · 2022-06-28T11:56:36.000Z

Thanks, @fgm @mvdan @fweimer-rh .
I see. The commands and needs for statically linked compilation may vary between golang versions, so it is difficult to do the work to provide a convenient --static cmd parameter for go build.

Answer 35 · 2022-07-02T16:27:55.000Z

@MaoJianwei go build -static is part of Go and would get updated to do the right thing before release -- writing a test for it should be easy enough.

Answer 36 · 2022-07-11T14:49:35.000Z

Let me rephrase: The proposed go build -static would be part of Go, and would be updated to do the right thing.

See also