From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32549 invoked by alias); 18 Jun 2018 13:42:05 -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 32531 invoked by uid 89); 18 Jun 2018 13:42:04 -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=crazy, difficult, our, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Subject: Re: [PATCH 00/20] RFC: Add the CPU run-time library for C To: Siddhesh Poyarekar , "H.J. Lu" Cc: GNU C Library References: <20180612221939.19545-1-hjl.tools@gmail.com> From: Florian Weimer Message-ID: <57ec6b9e-ed17-f94d-0bdc-e225381e6a5a@redhat.com> Date: Mon, 18 Jun 2018 13:42: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: 8bit X-SW-Source: 2018-06/txt/msg00486.txt.bz2 On 06/13/2018 04:19 PM, Siddhesh Poyarekar wrote: > On 06/13/2018 06:55 PM, Florian Weimer wrote: >> 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. > > Why so?  Are there dependencies that avoid splitting out a > libstring_pic.a that builds only the string routines and then links that > into everything that needs it, i.e. libc.so, libc.a, libc-rt.so, etc.? I don't think there are any actual obstacles in the code, or at least not that many. It's just that it would be difficult to express this in the current build system, in a concise manner. > Ideally I'd like to see something like this happen but it is a crazy > long term project: > > 1. Put sysdeps for specific routines into their respective directories. > That is, elf/sysdeps, math/sysdeps, string/sysdeps, etc. > > 2. Support building all of these as separate lib*_pic.a that then gets > integrated at the top > > 3. Add a new target in string/Makefile that builds a libstring-rt.so > from its libstring_pic.a > > 4. Pull string out into a separate project and make it a submodule of > the glibc repo. > > This could even get used to replace libio in future, where > libio-3.0_pic.a gets linked in by default and libio-2.x_pic.a is built > into a libio_compat.so that can then be preloaded for programs that need > it. Not sure if this is the right approach. Another way of doing this would involve linking almost all of libc_pic.a (basically everything without initializers), while restricting symbol visibility to a subset of the symbols. ld should discard all objects which define only unexported and otherwise unused symbols. Thanks, Florian