Re: [PATCH 00/20] RFC: Add the CPU run-time library for C

[Florian Weimer <fweimer at redhat dot com>]

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