> On 2 Aug 2019, at 09:02, Michael <aixto...@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-le...@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/OZX3XG33TZ5GVBL4VMNPH3YFJZC7B27Z/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@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/JTQMZ6ZX43KHA254EVXI36YZU2PXYFO6/
