-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: fix Python Arm build #3409
ci: fix Python Arm build #3409
Conversation
300f9bb
to
dd53923
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems ok. We only use libc indirectly anyways so I wouldn't expect too much of a perf hit. However, we don't really have perf benchmarks for lancedb so I'm not sure it's easy to really know. Though, if performance is critical for users, then I guess they should be building natively anyways.
I'll point out that manylinux 2014 is, unfortunately, also EOL.
You're right about the cloud instances though. AMI2 isn't EOL until 2030 and is on glibc 2.26 so I'm not sure there is a good choice and 2014 seems as good as anything for now I guess.
Actually, I can just add 2_28 to the build matrix like we have for x86_64. |
Based on changes made in Lance: * lancedb/lance#3409 * lancedb/lance#3411
We were using deprecated 2_24 for ARM, but that seems to have some issues. Dropping down to 2_17 for now to keep wide support, as I believe some of the popular cloud linuxes don't have >=2.28 glibc.