-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[wheel] Remove vendored libcrypt #22392
[wheel] Remove vendored libcrypt #22392
Conversation
@drake-jenkins-bot linux-jammy-unprovisioned-gcc-wheel-experimental-release please |
+@mwoehlke-kitware for feature review, please. |
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.
Those "manylinux somethings" appear to relate to pypa/manylinux#305 (see also RobotLocomotion/pip-drake#15). However, it looks to me as if Python has always "promised" to make that API available, whether or not a module actually needs it (which we, presumably, don't).
I'm a little twitchy because our baseline is still 3.10 which has not deprecated its availability, though again, since it seems we don't actually need it, I guess we can try, and hope nothing breaks.
Reviewed 3 of 3 files at r1.
Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers
Suggestion:
This library was being pushed on us by python3-config because CPython
guaranteed its availability prior to 3.13 (deprecated in 3.11). However,
Drake has never actually needed it; therefore, excise it from the list
of linked libraries so that we can stop vendoring it.
This library was being pushed on us by python3-config because CPython guaranteed its availability prior to 3.13 (deprecated in 3.11). However, Drake has never actually needed it; therefore, excise it from the list of linked libraries so that we can stop vendoring it.
f65e4e6
to
5b0bfb2
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.
I'm fairly confident that nothing in our native modules actually needs it.
Even on Fedora where they played SONAME games with libcrypt.so.2
, users can sudo dnf install libxcrypt-compat
to put back libcrypt.so.1
. I suppose there might still be a load-time problem if nothing actually loads that library via some NEEDED? Meh.
Anyway, the bottom line is that we only support Ubuntu and our CI tests prove this is OK on Ubuntu. If users on other platforms experience new problems because of this, we can triage those reports for whatever is actually happening.
+@ggould-tri for platform review per schedule, please.
Dismissed @mwoehlke-kitware from a discussion.
Reviewable status: LGTM missing from assignee ggould-tri(platform)
-- commits
line 5 at r1:
Done.
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.
Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: complete! all discussions resolved, LGTM from assignees ggould-tri(platform),mwoehlke-kitware
It's been deprecated in CPython for couple years now. When
python3-config --ldflags
on Ubuntu tells us that we should always be linking-lcrypt
, it is lying to us.This change is