Let's hope it's enough :)

Statically linking a single library on all platforms is very unintuitive. The omnibus is the only place where we've had this problem, why not just statically link the omnibus compiler in it's entirety? This seems like a bad hacky solution which pollutes the standard library with fixes for problems in the omnibus.

If you end up doing this at least make it enabled only with -Dstatic_libcpp, but I'd much prefer a statically linked compiler binary.

I think this violates the license

I think this violates the license

Nope, apparently not true

Why not to link everything statically by default, as Go does?

Fully linking the compiler statically in omnibus would avoid many portability issues, indeed. It works, I did it before to bootstrap the compiler on AlpineLinux.

Now, glibc (GNU libc) isn't really statically linkable (different warnings that libraries may be loaded at runtime), and there seems to be an issue with boehm-gc and musl-libc (when statically linked), as per #4276.

@akzhan Because it's not what almost all other compiled languages do. We should make static linking as easy as passing --static in most cases (we're not there yet) but it should not be the default: the default should be what the rest of the platform uses by default.

Go is an oddity, users should be able to choose how to link. Besides, I think go statically links because it very usually doesn't actually link to anything apart from Go code, because it uses no C libraries at all. I could be entirely wrong but I think go's stdlib is entirely self-contained not using libc at all.

I am no expert on linking and stuff, so maybe my 2cents are not worth listening... but I'd support the suggestion to not to link stdc++ statically in general, but only on the builds for distribution (i.e. in omnibus). And perhaps only for platforms where problems have been reported that some older OS versions do not provide the required library version.

Working on this, I've just found that statically linking libstdc++ isn't that trivial. They suggest there to use RPATH, instead, that tells the linker where to look for dynamic libs.

The good news is - the compiler created via omnibus currently uses that RPATH to load its libraries. So the only thing left to do is ship a libstdc++.so.6 with the packages we generate.

I've tested this on an Ubuntu 14.04.1, and it worked. I'm testing this on a couple other distros and, if that works, make the corresponding PRs/fixes.

If anyone knows a reason why this is not a great option, please do comment :)

@matiasgarciaisaia If the entire binary is statically linked and does not use dlopen to load a C++ library (one that depends on libstdc++) it is fine. libc uses dlopen which makes it quite annoying to statically link for other reasons (musl would be a great solution here).

However, this is a great temporary solution for the next crystal release. 0.23.0 contains quite a few bugs so a simple fix is good. However, I think that providing a statically linked compiler binary which is guaranteed to work on all distributions would be fantastic.

Relying on RPATH sounds good.

A fully static compiler would be gorgeous. It could run on whatever linux distribution, and whatever libs and libc are installed. Yet, we need some (hard) investigation on the unwind segfault when musl-libc is statically linked :(

Hi there! During this days I've found that the greater GLIBCXX dependency wasn't due to LLVM itself, but due to the distros that were used to generate the LLVM bins we use for compiling Crystal.

So I've re-built LLVM on the older distros (the ones we were using before 0.23.1), and Crystal recovers compatibility that way.

The full-static compiler is something we want to do in the mid/long term, but I'm closing this PR because it won't happen now for this issue.

Thanks to everyone for your input - really, it was much helpful!