Message386197
> 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 |
|
Date |
User |
Action |
Args |
2021-02-03 11:53:09 | ncopa | set | recipients:
+ ncopa, christian.heimes |
2021-02-03 11:53:09 | ncopa | set | messageid: <1612353189.34.0.565645217954.issue43112@roundup.psfhosted.org> |
2021-02-03 11:53:09 | ncopa | link | issue43112 messages |
2021-02-03 11:53:09 | ncopa | create | |
|