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 Wed, Jun 13, 2018 at 6:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.
True.
>>> 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.
Each user needs to evaluate pros and cons.
> 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
Excluding the cpu-rt-c directory and x86 directories, my approach added
one IS_IN (libcpu_rt_c) check to elf. It can be hardly called "tons".
> this is implemented looks like quite a bit of an additional burden, for each
> architecture that chooses to participate.
That is true. My approach avoids duplicated efforts.
> 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.
>
libcpu-rt-c targets systems with older glibcs. There is no need for it on
systems where glibc is up to date.
--
H.J.