Repository navigation
Add --soabi option to configure #54471
Description
| BPO | 10262 |
|---|---|
| Nosy | @warsaw, @doko42, @amauryfa, @merwok, @bitdancer |
| Files |
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:
assignee = 'https://github.com/warsaw'
closed_at = <Date 2013-11-10.19:26:04.603>
created_at = <Date 2010-10-31.12:07:21.917>
labels = ['type-feature', 'build']
title = 'Add --soabi option to `configure`'
updated_at = <Date 2013-11-10.19:26:04.602>
user = 'https://bugs.python.org/Arfrever'bugs.python.org fields:
activity = <Date 2013-11-10.19:26:04.602>
actor = 'barry'
assignee = 'barry'
closed = True
closed_date = <Date 2013-11-10.19:26:04.603>
closer = 'barry'
components = ['Build']
creation = <Date 2010-10-31.12:07:21.917>
creator = 'Arfrever'
dependencies = []
files = ['19443', '19878']
hgrepos = []
issue_num = 10262
keywords = ['patch']
message_count = 18.0
messages = ['120044', '121252', '121558', '122602', '122792', '122793', '122794', '122798', '122873', '122938', '122939', '122946', '122947', '123923', '123942', '123943', '123945', '202558']
nosy_count = 6.0
nosy_names = ['barry', 'doko', 'amaury.forgeotdarc', 'eric.araujo', 'Arfrever', 'r.david.murray']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10262'
versions = ['Python 3.2']
Activity
Arfrever commentedon Oct 31, 2010
Some packagers might want to disable ABI flags. The attached patch adds --disable-abi-flags option to
configure.doko42 commentedon Nov 15, 2010
I think this is not a good idea, because then you have different names for extension modules, which will be recognized by one configuration but not the other. This configure option should not change the sonames. If this option is to keep pathes like /usr/local/include/python3.2 (instead of /usr/local/include/python3.2mu) or /usr/local/lib/python3.2/config (instead of /usr/local/lib/python3.2mu/config), then fine with me. Although in this case we should make sure that these pathes are available in the sysconfig module.
warsaw commentedon Nov 19, 2010
What specifically is the motivation for this option? Since abiflags are used in many places, most of which are hidden from the end user, why are they a problem, and what are the use cases for suppressing them?
If it's to eliminate the abiflags in the binary names, then I can get on board with that. (IOW, instead of symlinking python3.2 -> python3.2dmu, just write out python3.2 and avoid the extra symlinks).
Please clarify.
Arfrever commentedon Nov 28, 2010
I want to eliminate ABI flags in file names.
amauryfa commentedon Nov 29, 2010
I agree with the intent: package maintainers, or people compiling python for their own need, should have the right to choose the suffix used by extension modules.
I suggest another option though, one that directly sets the SOABI used in extension file names. This would override both the default SOABI (python3.2) and the flags added to it.
For example, when no flag is passed to ./configure, the default is equivalent to
--soabi=cpython3.2m
And we can get the 2.x naming scheme back simply with:
--soabi=
Yes, this flag should be only used when you know what you are doing. This builds a version of python that will be unable to load extensions built by other people.
doko42 commentedon Nov 29, 2010
I still fail to see the rationale for being able to build with a different soabi name. But anyway, as long as the default is to build with the soabi name, I'm +/-0 on this option.
Note that the soabi name isn't fixed but changes with other configure options.
amauryfa commentedon Nov 29, 2010
warsaw commentedon Nov 29, 2010
+0 for Amaury's suggestion in msg122792. Who wants to write that patch? I'd happily review it.
[-]Add --disable-abi-flags option to `configure`[/-][+]Add --soabi option to `configure`[/+]amauryfa commentedon Nov 30, 2010
Here is a first patch that adds the "--with-soabi" option.
--with-soabi=yes or --with-soabi sets SOABI to the computed value (cpython-32m when I tried it). This is the default behavior on Linux.
--with-soabi=no or --without-soabi sets SOABI to the empty string, and removes the additional searched extensions from imp.get_suffixes(). This is the default behavior on all other platforms.
--with-soabi=<tag> sets SOABI to the given string. Then imp.get_suffixes() contains the following extensions: [".tag.so", "module.tag.so", ".so", "module.so"]
The patch is not yet complete, it does not modify the suffixes in the dynload_* files for platforms other than Linux.
Windows support will come after. It requires more thoughts because there is no Makefile to read at runtime.
But it's the first time I change the ./configure script, so please comment on this first patch.
warsaw commentedon Nov 30, 2010
Of course, you don't change configure directly, you change configure.in and let autoconf update the configure (but you already know that I'm sure :).
The patch looks fairly reasonable, though I haven't tried it. One question: does $SO have the same value after your patch as before? That's a variable available via sysconfig and it looks like you're removing a block of code that sets it.
amauryfa commentedon Nov 30, 2010
The value of get_config_var("SO") is the same as before, something like ".cpython-32.so" by default on Linux. (see, I just moved the line SO=.$SOABI$SO at the bottom of the patch).
In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple" extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)
Is there a way to write unit tests for all this? This would prove that the default behavior is the same as before.
warsaw commentedon Nov 30, 2010
On Nov 30, 2010, at 10:12 PM, Amaury Forgeot d'Arc wrote:
Cool, thanks.
Since I used SOABI earlier, what do you think about SOBASE and SOEXTRA for
consistency?
It would, but I couldn't think of a way to do that reliably across platform.
amauryfa commentedon Nov 30, 2010
Let's test Linux at least, then.
bitdancer commentedon Dec 14, 2010
What's the status of this? It sounds like it something that should be taken care of before the 3.2 release, but I know there has been other activity in this area and I haven't looked closely enough to understand the issues involved.
doko42 commentedon Dec 14, 2010
shouldn't that option work on platforms too, which currently default to not using the soabi? It would make sense for all posix, and macos, maybe not for Windows.
amauryfa commentedon Dec 14, 2010
The soabi tag could be useful on Windows as well, for example if some package maintainer chooses another version of the compiler, or a custom version of MSVCRT.
And FWIW, PyPy currently uses "--soabi=pypy-1.4" on all platforms: "import foo" will load foo.pypy-14.so (foo.pypy-14.pyd on Windows). There are also some specific abiflags. A difference is that PyPy will also ignore the default foo.so, because extension modules built for CPython will likely crash with PyPy.
warsaw commentedon Dec 14, 2010
Amaury, did you see my suggestion re $SOBASE and $SOEXTRA?
Also, do you think you can write some tests, even if they only run on a single platform?
I suspect the Makefile.pre.in part of the patch will have to be updated now.
Please be sure to test your changes with --enable-shared as well to make sure everything gets installed correctly.
warsaw commentedon Nov 10, 2013
I think we've had plenty of time to adjust to the abi tags. Does anybody think that nearly 3 years later anything really needs to be done here?