On 2 Aug 2019, at 09:02, Michael <aixtools@felt.demon.nl> wrote:

On 01/08/2019 11:07, Michael wrote:
So, to my question: currently, for AIX get_host_platform returns
something such as: aix-6.1.

Considering above: what would you - as more expericenced with
multi-oslevel packaging and low levels are accepted by high-levels, but
not v.v.
"What should the AIX get_host_platform() string contain?"

At a minimum I forsee:        return "%s-%s.%s-%s" % (osname, version,
release, platform.architecture()[0])

But this does not address potential issues where the TL level within a
version.release has changed. (X.Y.TL5 built packages MIGHT work on
X.YTL4, but there is no reason to expect them to.

So, I would look to something that remains recognizable, but uses
different 'punctuation'

e.g., oslevel -s returns a string such as: 6100-09-10-1731

Then using the equivalent of:

version, release, service, builddata = '6100-09-10-1731'.split('-')

return "%s-%s.%s.%s-%s" % (osname, version, release, service,

What I forgot to mention - there is likely incompatibilities when
different compilers are used. This is definetly the case when source
files need a C compiler - and I fear that the different run-time
environments of gcc versus xlc (which does not need/link to glibc).

So, how does, e.g., macos account for differences between clang and gcc
compiled executables and modules. Or are both compilers "gnu" oriented?

For macOS GCC and clang generate compatible code, that’s not a problem. 

For platform versions the situation is slightly more complicated, but it is in general possible to 
build on newer releases of macOS than you deploy on. However, this requires some
support from the code you are building, such as not using APIs that aren’t available on the
older version. That generally can cause issues with projects that use configure and can
automatically pick up symbols available on the build platform.

The Linux setup might be more interesting for you in that regard. The “manylinux” project [1] specifies how to build wheels that work on multiple linux versions, regardless of the version of libc.  In short this works by building with an older libc, to ensure that the wheels only use symbol versions that are available on all supported linux versions.

[1] https://github.com/pypa/manylinux



Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-leave@python.org
Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/OZX3XG33TZ5GVBL4VMNPH3YFJZC7B27Z/