The flag was added by commit ecd6463, not sure why though. The -w flag is to disable DWARF generation (which, as far as I can see, can be stripped using strip).

I think it's better to drop the flag entirely, and instead add EXTRA_LDFLAGS="-w -s" to script/release.sh instead. Here -s is
to disable symbol table (which further reduces the binary size).

@kailun-qin can you do that? While at it, please don't use markdown in commit subject.

Interestingly, even the binary build with -w -s is strippable further; here is a comparison:

[kir@kir-rhat runc]$ ls -l *runc-static*
-rwxrwxr-x. 1 kir kir 15527744 Jun 30 10:52 runc-static
-rwxrwxr-x. 1 kir kir 11599152 Jun 30 11:01 runc-static-s
-rwxrwxr-x. 1 kir kir 13137864 Jun 30 10:52 runc-static-w
-rwxrwxr-x. 1 kir kir 11599152 Jun 30 10:51 runc-static-w-s
-rwxrwxr-x. 1 kir kir 10169624 Jun 30 10:53 stripped-runc-static
-rwxrwxr-x. 1 kir kir 10169624 Jun 30 11:01 stripped-runc-static-s
-rwxrwxr-x. 1 kir kir 10169624 Jun 30 10:53 stripped-runc-static-w
-rwxrwxr-x. 1 kir kir 10169624 Jun 30 10:53 stripped-runc-static-w-s

(in the listing above the first four items are builds with and without -w and -w, and the last for are stripped versions of those).

@kolyshkin GNU strip used to break stack backtraces in Go programs, while -w would reduce the size of the binary without that problem (in fact there are some go-nuts threads from a long time ago where folks were told to not use GNU strip on Go binaries). Now, it seems that this is no longer the case so maybe we can just use strip directly?

@kolyshkin @cyphar Thanks for the comments, updated! I intended to propose to add -s (for release) by default as well.
See if you would like to use strip v.s. -w -s. The -w -s approach would not introduce any dependency, for example strip may not be available on Windows systems.

Now, it seems that this is no longer the case so maybe we can just use strip directly?

To me it makes sense to use both -w -s and strip. The linker flags are merely to save some CPU and disk I/O.

As a fun experiment, I just tried to upx the resulting binary, slashing its size from 9.7M down to 3.5M. Apparently everything still works, the only downsides are:

• the startup is 0.1s slower;
• go version -m <binary> no longer works.

As a fun experiment, I just tried to upx the resulting binary, slashing its size from 9.7M down to 3.5M. Apparently everything still works, the only downsides are:

• the startup is 0.1s slower;
• go version -m <binary> no longer works.

Exactly, upx is usually considered as one of the ultimate approaches (available) for binary size optimization, though may incur some performance trade-offs.

@kolyshkin @cyphar Would you please kindly take another look when you get a chance? Thanks!

@kailun-qin please squash your commits, it's easier to review and in general makes more sense in this case.

The only other nit I see is the word "proposes" in the commit description. Once merged, it's no longer a proposal but a factual change, so please change the description accordingly ("This patch does this and that because ...", or, yet better, "Do this and that
because...").

@kailun-qin please squash your commits, it's easier to review and in general makes more sense in this case.

The only other nit I see is the word "proposes" in the commit description. Once merged, it's no longer a proposal but a factual change, so please change the description accordingly ("This patch does this and that because ...", or, yet better, "Do this and that
because...").

Squashed and updated the commit message. PTAL, thanks!

Needs a rebase. I am carrying this in #3099 and have rebased it in there, so I guess we can close this one.