This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/20] RFC: Add the CPU run-time library for C
On 06/13/2018 12:13 PM, H.J. Lu wrote:
libcpu-rt-c can be built on any systems with required GCC and binutils.
The resulting libcpu-rt-c.so is binary compatible with ALL versions of
x86-64 glibcs.
Yes, but that doesn't work for every distribution.
I don't doubt that this can be useful (but I doubt it will completely stop
string function backports), but building and shipping this library as part
of glibc seems detrimental to its goals.
I don't expect it will be shipped as the part of glibc. But when people
ask for better string/memory functions on Skylake running RHEL 7, I
can point them to libcpu-rt-c or I can build one for them on Fedora 28.
We cannot produce supportable builds on Fedora 28. Supported builds
must come out of the build system. It so happens that we have Developer
Toolset (DTS) which matches upstream version requirements, and that is
available in certain product build environments, so we could produce
supportable builds with this hybrid approach. But to give a different
example: I don't think Debian has this capability, particularly when it
comes to binutils.
All that wouldn't be a problem if the changes are fairly isolated and
there wouldn't be tons of conditionals in generic code, but the current
approach this is implemented looks like quite a bit of an additional
burden, for each architecture that chooses to participate.
It would be another thing to build a static PIC string library from
sources and link that both into libc.so and this new support library.
Then the build process would at least be aligned. But I don't think our
current build system is up for that.
Thanks,
Florian