move `x86_64-linux` to be based on `ubuntu:20.04`

[flavorjones]

Exploration of a solution for #122

Changes:

• Remove math.h patch. This should no longer be needed since it existed only to provide some additional compatibility for musl target systems in the "x86_64-linux" gems. Closes #120.
• Move the x86_64-linux-gnu and x86-linux-gnu images to be based off ubuntu:20.04 Remove all manylinux-specific build steps from the dockerfile template.

[flavorjones]

@larskanis I'd love your opinion on this change if you get a few minutes to review.

[flavorjones]

I've got a fix for the x86 image almost ready to go.

[ianks]

Would this mean that precompiled gems could no longer run on old libc?

[flavorjones]

@ianks Correct. The min glibc version would update from 2.17 to 2.29, and versions older than 2.29 would not be supported. What platforms are you targetting?

We will need to update the min glibc version in some way at some point in time. If you can help me understand your requirements maybe we can make better decisions. Ideally I don't want to be supporting ancient systems for new gems and new versions of Ruby (especially if previous rake-compiler-dock images still support those ancient systems), for some definition of "ancient" that is informed by distro EOL and Python manylinux EOL.

[ianks]

We will need to update the min glibc version in some way at some point in time. If you can help me understand your requirements maybe we can make better decisions. Ideally I don't want to be supporting ancient systems for new gems and new versions of Ruby (especially if previous rake-compiler-dock images still support those ancient systems), for some definition of "ancient" that is informed by distro EOL and Python manylinux EOL.

I feel somewhat unqualified here, and for me personally I would prefer to be on some ubuntu. But I do know there are companies out there on old un-upgradable servers and I worry we could break things for them... But then again, they can always compile from source so maybe it doesn't matter?

[flavorjones]

@ianks Right, end users can still compile their own stuff on older systems if they need to -- there's an escape hatch if you consider precompiled gems to be an optimization and not a critical requirement for gem delivery.

Really, this comes down to: I'm willing to support old systems as long as it doesn't cost much in terms of effort and complexity. But we're at the point where continuing on manylinux2014 has been hard and just got harder.

[ianks]

Think I agree with you here. My one request would be that we look into the cross-rs images, since they've solved a lot of the traditional cross toolchain problems and offer some nice builtin features like qemu emulation, etc

[flavorjones]

@ianks I'm happy to chat about cross-rs at some point, but since they are also based on 20.04 (and presumably mostly-compatible) maybe we can move that discussion to a separate issue?

[flavorjones]

@larskanis Do you have any thoughts about this change? Unless you have strong objections, I'd like to merge it to make it easier to start testing downstream gems against the snapshot images.

[flavorjones]

Well, maybe we can start with this change, and if people ask for lower glibc requirements we can look into building/configuring the toolchain.