Produce statically linked oak_loader binary

[tiziano88]

Relies on the x86_64-unknown-linux-musl build target to produce a
fully static binary.

Checklist

• Pull request affects core Oak functionality (e.g. runtime, SDK, ABI)
  • I have written tests that cover the code changes.
  • I have checked that these tests are run by Cloudbuild
  • I have updated documentation accordingly.
  • I have raised an issue to
    cover any TODOs and/or unfinished work.
• Pull request includes prototype/experimental work that is under
  construction.

[tiziano88]

Interestingly, this now causes the binary to fail at runtime because of the C++ / Rust linkage. I guess the C++ side of things still relies on dynamically linking libc, and it panics when it's not.

@daviddrysdale why did this not fail at link time? And what should we do about it?

2020-04-17 21:06:26,871 DEBUG [oak_glue] {0}: channel_close(11969800758152741177) -> Ok(())
+ [[ base != \n\o\n\e ]]
+ kill -s SIGTERM 173803
+ stop_server
*** Aborted at 1587153986 (unix time) try "date -d @1587153986" if you are using GNU date ***
+ kill -s SIGTERM 173803
PC: @                0x0 (unknown)
*** SIGTERM (@0x252250002a269) received by PID 173803 (TID 0x7fb8f86d8b40) from PID 172649; stack trace: ***
    @     0x7fb8f8be8520 (unknown)
    @     0x7fb8f87d1f79 syscall
    @          0x17c72c5 absl::synchronization_internal::Futex::WaitUntil()
    @          0x17c6d62 absl::synchronization_internal::Waiter::Wait()
    @          0x17c5e5b AbslInternalPerThreadSemWait
    @          0x17c226a absl::synchronization_internal::PerThreadSem::Wait()
    @          0x17c17f9 absl::Mutex::DecrementSynchSem()
    @          0x17af1d4 absl::Mutex::Block()
    @          0x17b1755 absl::Mutex::LockSlowWithDeadline()
    @          0x17b05fe absl::Mutex::LockSlow()
    @          0x17b0d75 absl::Mutex::LockWhen()
    @          0x17ad330 absl::Notification::WaitForNotification()
    @           0x77db51 main
    @     0x7fb8f8703bbb __libc_start_main
    @           0x77d02a _start
    @                0x0 (unknown)

[tiziano88]

cc @ipetr0v

[daviddrysdale]

I guess we may need to add something equivalent to the rust-repository-set in WORKSPACE once we've sorted out #724?

[tiziano88]

I think so

[daviddrysdale]

I think that call stack is a red herring – the fragment of log just shows a script sending in a SIGTERM and the binary then dying with a SIGTERM¹ while waiting on a semaphore/futex, which seems reasonable. Were there other failure symptoms? Anything odd-looking if you run under strace -o syscalls.txt <command> ?

---

[1]: The SIGTERM now shows a call stack due to dd33b76. Ideally, we should fix the run_example TODO to do something more gradual (e.g. send SIGINT first, then only move on to SIGTERM; old experiment here).