Is it possible to make the go executable even smaller?

[ChrisLu]

Maybe the idea is too wild. Is it possible to make the go executable even smaller?

The go executable is pretty small. Usually 3M or so. But a simple gzip can compress it to about 1M.

So I think maybe a simple compression can be added just before launching the actual executable.

[minux]

You can always upx(1) the binary.

[Miki Tebeka]

upx does not work on Go executables, see http://sourceforge.net/tracker/?func=detail&atid=102331&aid=3408066&group_id=2331.

[Archos]

Build a program to compress/decompress an executable, and execute the binary at decompress it.

[Carlos Castillo]

Many gzip implementations have a gzexe binary that will do this.

[Rob Pike]

Write less code.

-rob

[minux]

for the record, latest version of upx (3.08) can compress linux/386 binaries produced by go.

On Wednesday, August 22, 2012, Miki Tebeka wrote: 

upx does not work on Go executables, see http://sourceforge.net/tracker/?func=detail&atid=102331&aid=3408066&group_id=2331.

upx can't not handle linux/arm and linux/amd64 binaries produced by go,

and I will look into these problem.

update:

the linux/arm problem should be fixed by CL 6475044,

i'm investigating the linux/amd64 problem now.

the compress rate is pretty good, about 30%, and the execution time penalty is unnoticeable

even on underpowered ARM machines.

[tiny_dust]

3M is a extremely small size. :)

I am maintaining one java project, which is in size of 89M , bundled
with many many jars.

[Miki Tebeka]

Great news, thanks.

[bryanturley]

No one mentioned strip?
If you don't care about debugging this could make it smaller I believe.
I haven't used it myself though (with go binaries) so good luck.

[Aram Hăvărneanu]

If you don't care about debugging your code it doesn't mean an
administrator that debugs his stack doesn't want to debug your failing
code. Stripping symbols is awful.

--
Aram Hăvărneanu

[bryanturley]

Heh, well i did say "I haven't used it myself though (with go binaries) so good luck."
And I believe with most of the big linux distros you have to install the debug symbols separately.

[Kyle Lemons]

On Thu, Aug 23, 2012 at 6:49 AM, pw <wang.p...@gmail.com> wrote:

Stripping executable in an embedded production environment is common practice.  Having the user debug production binary, however, is uncommon.  Besides, the symbols can be side-loaded into gdb when the binary image doesn't a set built-in.

I don't think strip or gdb understand Go binaries well enough for either of those things to behave the same way they do with C.

 

When somebody worries about minimizing space, then they're starting down the production binary path.

Not always ;-).  There is always the chance it's someone prematurely optimizing for space.

[elij]

On Thursday, August 23, 2012 at 10:18 AM, Kyle Lemons wrote:

> On Thu, Aug 23, 2012 at 6:49 AM, pw <wang.p...@gmail.com (mailto:wang.p...@gmail.com)> wrote:
> > Stripping executable in an embedded production environment is common practice. Having the user debug production binary, however, is uncommon. Besides, the symbols can be side-loaded into gdb when the binary image doesn't a set built-in.
>
> I don't think strip or gdb understand Go binaries well enough for either of those things to behave the same way they do with C.

go install -ldflags '-s'

Admittedly, I haven't used it much.

[Mike Rosset]

UPX does works last I check, but only on 32bit elf binaries.

[Guillermo Estrada]

Posted this on another thread also, just for search result sake.

upx does not work on Go executables, see http://sourceforge.net/tracker/?func=detail&atid=102331&aid=3408066&group_id=2331.

Issue still open right AFAIK. At least for Windows and Mac (32 and 64 bit) I found this one:

http://www.matcode.com/mpress.htm

Works wonders with go executables on windows x64 (19% final size on a server) Hope it helps.

I have not tested this on Mac.

On Tuesday, August 21, 2012 12:20:57 PM UTC-5, ChrisLu wrote: