msg120044 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-10-31 12:07 |
Some packagers might want to disable ABI flags. The attached patch adds --disable-abi-flags option to `configure`.
|
msg121252 - (view) |
Author: Matthias Klose (doko) * |
Date: 2010-11-15 23:57 |
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.
|
msg121558 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-11-19 18:50 |
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.
|
msg122602 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-11-28 02:18 |
I want to eliminate ABI flags in file names.
|
msg122792 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-11-29 12:10 |
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.
|
msg122793 - (view) |
Author: Matthias Klose (doko) * |
Date: 2010-11-29 12:15 |
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.
|
msg122794 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-11-29 12:21 |
> Note that the soabi name isn't fixed but changes with other configure options.
The default value, yes.
But my proposal of a --soabi option would not respect this. The caller is responsible for changing the --soabi value when he adds other options.
|
msg122798 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-11-29 13:58 |
+0 for Amaury's suggestion in msg122792. Who wants to write that patch? I'd happily review it.
|
msg122873 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-11-30 00:16 |
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.
|
msg122938 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-11-30 22:03 |
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.
|
msg122939 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-11-30 22:12 |
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.
|
msg122946 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-11-30 22:29 |
On Nov 30, 2010, at 10:12 PM, Amaury Forgeot d'Arc wrote:
>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).
Cool, thanks.
>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)
Since I used SOABI earlier, what do you think about SOBASE and SOEXTRA for
consistency?
>Is there a way to write unit tests for all this? This would prove that the
>default behavior is the same as before.
It would, but I couldn't think of a way to do that reliably across platform.
|
msg122947 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-11-30 22:31 |
Let's test Linux at least, then.
|
msg123923 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-12-14 03:19 |
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.
|
msg123942 - (view) |
Author: Matthias Klose (doko) * |
Date: 2010-12-14 13:49 |
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.
|
msg123943 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-12-14 14:20 |
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.
|
msg123945 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-12-14 14:38 |
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.
|
msg202558 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2013-11-10 19:26 |
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?
|
|
Date |
User |
Action |
Args |
2022-04-11 14:57:08 | admin | set | github: 54471 |
2013-11-10 19:26:04 | barry | set | status: open -> closed resolution: wont fix messages:
+ msg202558
|
2010-12-14 14:38:00 | barry | set | messages:
+ msg123945 |
2010-12-14 14:20:32 | amaury.forgeotdarc | set | messages:
+ msg123943 |
2010-12-14 13:49:49 | doko | set | messages:
+ msg123942 |
2010-12-14 03:19:44 | r.david.murray | set | type: enhancement
messages:
+ msg123923 nosy:
+ r.david.murray |
2010-11-30 22:31:09 | amaury.forgeotdarc | set | messages:
+ msg122947 |
2010-11-30 22:29:16 | barry | set | messages:
+ msg122946 |
2010-11-30 22:12:25 | amaury.forgeotdarc | set | messages:
+ msg122939 |
2010-11-30 22:03:38 | barry | set | messages:
+ msg122938 |
2010-11-30 00:16:37 | amaury.forgeotdarc | set | files:
+ with-soabi.patch
messages:
+ msg122873 |
2010-11-29 13:59:20 | barry | set | title: Add --disable-abi-flags option to `configure` -> Add --soabi option to `configure` |
2010-11-29 13:58:52 | barry | set | messages:
+ msg122798 |
2010-11-29 12:21:49 | amaury.forgeotdarc | set | messages:
+ msg122794 |
2010-11-29 12:15:54 | doko | set | messages:
+ msg122793 |
2010-11-29 12:10:28 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages:
+ msg122792
|
2010-11-28 02:18:29 | Arfrever | set | messages:
+ msg122602 |
2010-11-19 18:50:23 | barry | set | messages:
+ msg121558 |
2010-11-15 23:57:55 | doko | set | nosy:
+ doko messages:
+ msg121252
|
2010-11-15 23:02:25 | barry | set | assignee: barry |
2010-11-01 17:50:27 | eric.araujo | set | nosy:
+ eric.araujo
|
2010-10-31 12:07:21 | Arfrever | create | |