Statically link linux build

[stopdropandrew]

stylua's linux build fails to run on Ubuntu 18:

./stylua: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./stylua)

One oddity was that --target must be passed explicitly, as documented by this blog post

[codecov]

Codecov Report

Merging #444 (2059ffe) into master (602d1a2) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #444      +/-   ##
==========================================
+ Coverage   96.42%   96.44%   +0.01%     
==========================================
  Files          14       14              
  Lines        5228     5257      +29     
==========================================
+ Hits         5041     5070      +29     
  Misses        187      187              

Impacted Files	Coverage Δ
src/formatters/expression.rs	97.04% <100.00%> (+0.12%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2241716...2059ffe. Read the comment docs.

[JohnnyMorganz]

Thanks for the PR!

Could we instead put this flag in the .cargo/config.toml file similar to this? https://github.com/rojo-rbx/rojo/blob/master/.cargo/config.toml
Hopefully that still should work (and maybe the target won't need to be specified anymore in the build command either?)

(Also no idea why the code coverage has changed here..., seems unrelated, probably flaky)

[stopdropandrew]

I did that initially, seen here https://github.com/JohnnyMorganz/StyLua/runs/6049194259?check_suite_focus=true and other action failures, but I was getting the same error mentioned in that blog post.

I thought the easiest solution was to statically link only the release build, rather than figuring out how to pass in --target to every command - it's not even clear that's possible. Do you have a preference?

[JohnnyMorganz]

Nope, no particular preference here!

Did a bit more digging into the actual cause of this issue (wasn't happening before), and stumbled across rust-analyzer having the same issue: rust-lang/rust-analyzer#11558

It turns out this is because they switched their CI to Ubuntu 20.04 from 18.04, and Rust now requires a newer version of glibc. Our action is on ubuntu-latest which defaults to 20.04.

Maybe instead of statically linking the whole C runtime here, we just downgrade our CI to Ubuntu 18.04? I think that should also fix the problem, and I don't see any downside to it

[LastTalon]

Maybe instead of statically linking the whole C runtime here, we just downgrade our CI to Ubuntu 18.04? I think that should also fix the problem, and I don't see any downside to it

I think this is the way to go. The issue is with incompatible ABI changes. The newer version will be able to handle the old version linking, just not the other way around.

Possibly in the future (depending on support) CI could even build for each version of libc? This may be unsupported by foreman workflows though.