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

rake-compiler / rake-compiler-dock

Easy to use and reliable cross compiler environment for building Windows, Linux, Mac and JRuby binary gems.

MIT License

78 stars 30 forks source link

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

Closed flavorjones closed 3 months ago

flavorjones commented 4 months ago

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 commented 3 months ago

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

flavorjones commented 3 months ago

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

ianks commented 3 months ago

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

flavorjones commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

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