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
stop using ranlib #75806
Comments
As far as I'm aware, every modern *nix's ar supports an "s" flag that removes the need to run ranlib separately on a a static library. We should just do that and stop running ranlib. That saves us some lines in configure.ac and the Makefile. |
Thanks ;-) |
Would it make sense to backport that to 3.6 as well? Currently this blocks https://bugs.python.org/issue28015 from being backported to 3.6 |
(I reopen the issue.)
There is a risk of regression. Does bpo-28015 fix really depend on this change? Benjamin wrote: "As far as I'm aware, every modern *nix's ar supports an "s" flag", but I'm not sure if Python 3.6 is only used on "modern Unix". Some people use AIX and HP-UX: does ar support "s" on these OSes? |
AIX supports the -s flag: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.cmds1/ar.htm#ar__row-d3e27561 |
Maybe it would be possible to keep ranlib in Python 3.6, but it seems safe to remove it. The master doesn't use ranlib and the compilation is fine in our large fleet of buildbot workers. I chose to backport the change to be able to backport the clang LTO fix. |
clang LTO fix: bpo-28015 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: