This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]