This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/20] RFC: Add the CPU run-time library for C
On 06/18/2018 07:11 PM, Florian Weimer wrote:
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.
That's generally true for anything we do with our build system; it is a
complex web of insanity. That is also why I suggested a project to
rework it so that it is more modular and has less tentacles across
subdirectories like it currently does.
I am hand-waving of course because it is quite a big project.
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.
Sure, that doesn't sound not too different from what I'm suggesting,
which is to drop everything deprecated from the main library and have it
loaded on demand.
Siddhesh