From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70445 invoked by alias); 13 Jun 2018 13:25:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 70435 invoked by uid 89); 13 Jun 2018 13:25:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=participate, shipping X-HELO: mx1.redhat.com Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C To: "H.J. Lu" Cc: GNU C Library References: <20180612221939.19545-1-hjl.tools@gmail.com> From: Florian Weimer Message-ID: Date: Wed, 13 Jun 2018 13:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00309.txt.bz2 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