From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97780 invoked by alias); 13 Jun 2018 13:41:14 -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 97763 invoked by uid 89); 13 Jun 2018 13:41:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pros, shipping X-HELO: mail-oi0-f66.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hFF2NULTP7nr7kVR58DdExt0HOCCqh1tO8VeSaYGyIg=; b=YEb1P2F9YymGd13xKnZOEaIyta+dJupVIpcvSL7jHkS3lbOGWv/o/51lMz8wWcDYmK EgtuArFAxZD0JDnvnoxSolMPvpIPTJnCsML3ml+8VMUecLcVvE6qVL//W0qoxWPLieJx He8ukxxFO/NQEC559LLqXPVPbNmkWthXfp2WSxAArpbgpGM3T5Dsj+RwyRHTILlkBKSV b8/hT/OcCDluJa20UfFHjTZNN9bV+23lhvYiisr5Ab3syF03J2LHwfqPJ1w7aN4csAOq irROkqjrzSmb8+eP5/0QwfVIWaTJaSp/i51cPxHmrdwNeBzZHwLmFG08EP5QTjMDTRLo cZJg== X-Gm-Message-State: APt69E2Amg5fBnQB8PfiFzHpf/EZM3RZi3H1yI/mZzcsCJMRkG5yDStN Vhrs+iwOSyLabIjMRGu3D8sTuKxea8as5cEx9FLzaA== X-Google-Smtp-Source: ADUXVKJ4czgm9h5MXi8PHiOYrOySND+qEB8g7ktS1nWxe94bwkSXjiE3/jdlE/JA7cj7KcQjqSGXhLVvOPu3MnTye9c= X-Received: by 2002:aca:47c6:: with SMTP id u189-v6mr4789874oia.100.1528897270177; Wed, 13 Jun 2018 06:41:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180612221939.19545-1-hjl.tools@gmail.com> From: "H.J. Lu" Date: Wed, 13 Jun 2018 13:41:00 -0000 Message-ID: Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-06/txt/msg00310.txt.bz2 On Wed, Jun 13, 2018 at 6:25 AM, Florian Weimer 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.