gokrazy / freeze

Little helper to create tar balls of an executable together with its ELF shared library dependencies. Useful for prototyping with gokrazy: https://gokrazy.org/prototyping/

Overview

With gokrazy, you can deploy your Go programs as appliances to a Raspberry Pi or PC (→ supported platforms).

For a long time, we were unhappy with having to care about security issues and Linux distribution maintenance on our various Raspberry Pis.

Then, we had a crazy idea: what if we got rid of memory-unsafe languages and all software we don’t strictly need?

Turns out this is feasible. gokrazy is the result.

→ Learn more at gokrazy.org

GitHub Repository structure

• github.com/gokrazy/gokrazy: system code, main issue tracker, documentation
• github.com/gokrazy/tools: SD card image creation code, pulling in:
  • github.com/gokrazy/firmware: Raspberry Pi 3 or 4 firmware files
  • github.com/gokrazy/rpi-eeprom: Raspberry Pi 4 EEPROM files
  • github.com/gokrazy/kernel: pre-built kernel image and bootloader config

Documentation

gokrazy.org uses hugo for creating and generating the website. You can find the hugo install instructions here: Install Hugo. With hugo you can write documentation in Markdown and generate a static website from it.

The website subdirectory is hugo’s root directory. In order to preview the documentation or to re-generate the website, switch the directory to website.

To preview the website, run the hugo webserver:

hugo serve

Generate the website:

hugo

The updated website content will be stored in the ./docs directory. Do not update anything here manually.

freeze's Issues

support cross compilation

The tc example on https://gokrazy.org/prototyping/ uses cross compilation.

freeze should work out of the box with binaries that are not for the host architecture.

compare with exodus

Could https://github.com/intoli/exodus replace freeze? Need to check if it works with gokrazy.

libresolv / libnss are not frozen (for iperf3, or wget)

When name resolution (via getaddrinfo) is broken due to lack of libnss*.so and libresolv*.so, iperf3 fails to start with an opaque error message (iperf3: error - unable to send control message: Bad file descriptor).

Looks like libnss_dns* and libresolv* are the minimum files we need for name resolution to work.

generate one tar ball, even when multiple binaries are specified

Refactor the way dependencies are foudn?

There are a couple of issues with the FindShLibs() function:

• Some executables like /usr/sbin/nft b0rk at no arguments passed and exit with an exit status of 1. I kid you not 🤦‍♂️ Whoever designed the nft tool this way, shame 😅
• Furthermore, I found that the LD_TRACE_LOADED_OBJECTS=1 seems to be a GNU LIBC thing only? This does not work on Alpine for example which uses musl? (I could be wrong) but I wasn't able to use freeze on Alpine.

[comment] same need, same solution

I came across the same need when packaging a python application into a standalone folder.

I used the same trick : embed libs given by ldd with the exe into a tarball. Work pretty well.

Since I'm more a shell guy than a go guy, I used the following:

# cd into dist folder
ldd $1       |  # list shared libs
  awk '$2 == "=>" { print $3 }' |  # format ldd output
  sort -u    |  # remove duplicated
  tar c -T - |  # tar from file list from stdin
  tar x         # untar in current folder