Natanael Copa <nc...@alpinelinux.org> added the comment:
> Do you have glibc and musl installed side by side? No. But there is nothing preventing me to have the libc runtimes installed in parallel with glibc. /lib/libc.so.6 /lib/libc.musl-x86_64.so.1 And it is not common that people copy libc.so.6 (with friends) to their alpine docker images to run both in same container. If that is a good idea is other discussion. I do understand that full ABI compatibility also may involve libc ABI version, but I think that is a slightly different problem. Newer versions of glibc and musl libc are backwards compatible. You can expect a binary built with old libc version to run with new libc. But you cannot expect a binary built with musl libc to run with gnu libc. gcc recognizes -linux-musl as a valid platform tuple different that differs from -linux-gnu: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/t-musl The standard autotools' config.guess[1] also recognizes -musl as different platform. $ ./config.guess x86_64-pc-linux-musl [1]: https://github.com/python/cpython/blob/12d0a7642fc552fa17b1608fe135306cddec5f4e/config.guess#L158 So I think it makes sense to treat *-linux-musl as a different platform than *-linux-gnu. If you still insist that this is only about calling convention and not platform, then I think you should at least clarify that in the configure.ac script to avoid confusion: sed -i -e 's/PLATFORM_TRIPLET/CALLING_CONVENTION_TRIPLET/g' -e 's/platform triplet/calling convention triplet/g' configure.ac ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43112> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
