please set a SOABI for MacOSX

[doko42]

BPO	23969
Nosy	@doko42, @ronaldoussoren, @ned-deily

^{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/ned-deily'
closed_at = <Date 2015-07-04.09:01:14.720>
created_at = <Date 2015-04-15.19:12:13.437>
labels = ['OS-mac', 'build']
title = 'please set a SOABI for MacOSX'
updated_at = <Date 2015-07-04.09:01:14.719>
user = 'https://github.com/doko42'

bugs.python.org fields:

activity = <Date 2015-07-04.09:01:14.719>
actor = 'ned.deily'
assignee = 'ned.deily'
closed = True
closed_date = <Date 2015-07-04.09:01:14.720>
closer = 'ned.deily'
components = ['Build', 'macOS']
creation = <Date 2015-04-15.19:12:13.437>
creator = 'doko'
dependencies = []
files = []
hgrepos = []
issue_num = 23969
keywords = []
message_count = 9.0
messages = ['241146', '241184', '241185', '243300', '243819', '243872', '243887', '244025', '246246']
nosy_count = 4.0
nosy_names = ['doko', 'ronaldoussoren', 'ned.deily', 'Arfrever']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue23969'
versions = ['Python 3.5']

[doko42]

split out from

http://bugs.python.org/issue22980#msg232065

please consider setting the SOABI for MacOSX. Afaics MacOSX is now the only major platform not setting these, at least including the SOABI. The idea is that it would be possible to ship "fat" wheels, containing extensions for every OS. Not sure what the PLATFORM_TRIPLET would be, maybe just something like macosx, or darwin, if the MacOSX extension itself is a fat build.

[doko42]

what about iOS? isn't __APPLE__ there defined too?

[ned-deily]

"what about iOS? isn't __APPLE__ there defined too?"

It is but we currently don't have any iOS-specific checks snywhere in CPython. I have an additional patch to handle iOS here but I didn't want to break builds until adding full support for iOS as part of bpo-23670.

[ronaldoussoren]

I'm in favour of using SOABI on OSX as well.

The build system currently uses "darwin" for the platform triplet, that's a bit to minimal. I'd prefer to use "macosx" instead of "darwin" for the platform name, the same as is done for platform specific directories/files in distutils.

I'm not sure yet about what to do with the hardware architecture and deployment target. On the one hand it could be nice to reflect those in the name of extensions, on the other hand that makes it harder to mix and match binaries.

In particular, a fat binary for Python with deployment target 10.5 can currently load single architecture extensions with a different deployment target. That is useful functionality to have (for example to be able to load C bindings for newer OSX libraries in a python.org binary, the newer OSX libraries don't support PPC and some of them even don't support 32-bit i386 code). It would be a shame when the extension name would have lie about what's actually inside.

BTW. It might be useful change the suffix for extensions as well when adding the SOABI. The extension is currently ".so" and might be changed to something like ".pyext" to make it clearer what the file is for. That would also make it possible to use custom icons for extensions in the Finder and be smarter about them in spotlight and quicklook.

[ned-deily]

Ronald, the change to set the SOABI was pushed several weeks ago (but, because I left out a #, the commit message did not also show up here as I intended):

New changeset 32c24eec035f by Ned Deily in branch 'default':
Issues bpo-22980, 23969: For OS X, use PEP-3149-style file names for extension
https://hg.python.org/cpython/rev/32c24eec035f

As noted in the commit message, the names are now of the form:

_ssl.cpython-35m-darwin.so

As was extensively discussed in bpo-22980, I chose to not try to add hardware architecture and deployment target to the file name as I think pip and friends are already managing this correctly (msg241254). We could change the name from -darwin to -macosx if you feel strongly about it but, if so, we should do that now, before beta1. I don't feel too strongly about it (e.g. "-darwin" vs "-macosx") but I would rather not re-open the discussion at this point if possible. Also, given the discussion there, I'd rather not attempt to change the extension from .so to something else; I think that is more likely to be disruptive to the external packaging ecosphere. So unless you *really* want it changed, I intend to let things stand for 3.5 as implemented in 32c24eec035f.

[doko42]

so what you could do is to define more than one SOABI. The code in
Python/dynload_shlib.c reads:

"." SOABI ".so",
".abi" PYTHON_ABI_STRING ".so",
".so",

so it still recognizes .so names. If you want to recognize architecture specific sonames, then you would need something like

"." "cpython-35m-<cpu>-darwin" ".so",
"." "cpython-35m-darwin" ".so",
".abi" PYTHON_ABI_STRING ".so",
".so",

that would prefer to load the most specific so. Unfortunately that would be also seen as the visible soname to build extensions, which is probably not something like you want.

I still would prefer to use darwin instead of macosx, because that's the way config.sub/config.guess recognizes this platform.

[ned-deily]

"If you want to recognize architecture specific sonames"

For OS X we don't have a need to recognize architecture specific sonames because we want to continue to defer to the operating system to make the decisions about which, if any, architecture binary to load from a single universal container ("fat") file.

[ronaldoussoren]

Ned: Keeping "darwin" as the platform tag is fine with me. It is slightly ugly because it doesn't match the platform tag used by distutils/setuptools, but is also something that most users won't use directly.

That said: there was some talk about supporting iOS on python-ideas a while back, and using "darwin" as the platform tag for both would mean that you couldn't have a tree with extensions for both at the same time (assuming you can have extensions on iOS in the first place, I haven't kept track about the possibilities for shared libraries on iOS and it wasn't possible in the past)

The suffix change would be nice to have, but I haven't thought about the implications for 3th-party tools at all. I agree that this could cause problems for them, and that's not worth the very minor improvement in nameing.

[ned-deily]

I think we can close this as finished. The only remaining item I can think of is to add something to the 3.5 What's New document but that should be done as part of bpo-22980 for all affected platforms.