Upgrade the build container for linux releases

[alexcrichton]

This is a continued effort to try and track down #2273 which came up
again and is still present in the current release binaries. Issues like
crystal-lang/crystal#4276 may indicate that C++ exceptions are just
somewhat broken with static linking when using alpine, but I've at least
locally been able to verify that upgrading the container produces
working binaries which previously segfaulted on some wasm files.

[alexcrichton]

I'm still not really sure what causes a fix here, but I'm sort of presuming that something was fixed somewhere along the way. The container here is based on Node's containers so the wasm2js tests can run, and the node-13 container for alpine is based on Alpine 3.10 instead of 3.9. This at least pulls in clang 8 instead of clang 5, and presumably a whole bunch of updates for other system libraries. I'm sort of hoping (guessing?) that the fix was somewhere in one of those updates to the unwinder that's linked in.

[alexcrichton]

Thanks for the quick merge @dschuff! Would y'all be up for making a new release to test out these binaries and hopefully fix the segfaulting issue for good?

[sbc100]

@alexcrichton is there a reason you need statically linked binaries? Could we not make do with building against an old/stable release and ditch this whole alpine linux thing? I imagine it might solve a bunch of you random problem too. Fully static linking and musl are both less trodden paths in the linux world.

[sbc100]

It looks like the static alpine builds were added by @jirutka , not you, which makes me think maybe those requirements don't come from you?

[dschuff]

For now I went ahead and tagged 1.39.1 to match up with Emscripten. There's a travis build running, which should result in a release you can try.

[alexcrichton]

@sbc100 for my use case at least fully statically linked binaries aren't necessarily required, it's just "something that continues to run on old distros" and the most robust way to do that has generally been with static linking. I'd personally be ok if the releases were done with an old glibc version.

Thanks for making a release @dschuff! I've tested those out and they look to work for me locally and are avoiding segfaults on Linux!

[jirutka]

It looks like the static alpine builds were added by @jirutka…

Yes, originally, but the current .travis.yml uses Docker 😞 and some image from DockerHub instead of simple alpine-chroot-install, so I I don’t have much common with it anymore.

The whole point of fully statically linked binaries is to provide binaries that run on all Linux systems (and on multiple architectures), not just those using glibc and in the “right” version.

[sbc100]

I think I understand the requirement to run on as many linux installs as possible. However, in my experience building against a stable distro such as debian/stable has always been sufficient for distributing developer tools (we do did this for nacl-sdk and also for chromium itself) and will satisfy the needs the vast majority of linux users.

Expecting upstream C/C++ projects to build and distribute completely static binaries seems out-of-scope for normal projects. Of course, this doesn't stop downstream distros from compiling against non-glibc libc's or building static binaries. Or am I missing something and there is something special about binaryen that warrants prioritizing glibc-free static builds?

[dschuff]

I don't think it warrants prioritizing static builds. But I would also say it hasn't been prioritized.