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, platform.architecture()[0])
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 <https://github.com/pypa/manylinux> Ronald
Michael
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/OZX3X...