Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Apr 2018 23:59:20 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Dimitry Andric <dim@FreeBSD.org>
Cc:        Brooks Davis <brooks@one-eyed-alien.net>, freebsd-toolchain@freebsd.org, Ali Mashtizadeh <ali@mashtizadeh.com>
Subject:   Re: splitting libc -> libc + libsys and static linking
Message-ID:  <20180403205920.GP1774@kib.kiev.ua>
In-Reply-To: <DCA75254-34A6-4391-9E26-780722484BF0@FreeBSD.org>
References:  <20180403203210.GA23045@spindle.one-eyed-alien.net> <DCA75254-34A6-4391-9E26-780722484BF0@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 03, 2018 at 10:39:44PM +0200, Dimitry Andric wrote:
> On 3 Apr 2018, at 22:32, Brooks Davis <brooks@one-eyed-alien.net> wrote:
> > 
> > We (mostly Ali) are working on a patch to to split the actual syscalls
> > (__sys_<foo>) out of libc and into a libsys.  For dynamic linking,
> > this is fairly straightforward (link libc against libsys, maybe as a
> > filter).  For static linking, I'm looking for feedback on the right
> > approach.  Do we link libsys.a into libc.a?  Do we try to teach all the
> > compilers to add -lsys?  I'm pretty sure we don't modify all the ports
> > that statically link programs.  Is there some easy approach I'm missing?
> 
> The approach chosen for e.g. libc++ (and before that, libstdc++), was to
> put all needed objects from the dependent libs in the same .a file.
This would make libsys.a half as useless.  One of the indended use of
libsys.a in the base system is to get rid of libc in rtld dependencies.
Try to experiment with the linker script for libc.a.

> 
> See:
> https://svnweb.freebsd.org/base/head/lib/libc%2B%2B/Makefile?revision=321369&view=markup#l61
> 
> and:
> https://svnweb.freebsd.org/base/head/gnu/lib/libstdc%2B%2B/Makefile?revision=315175&view=markup#l57
> 
> For dynamic linking, you could use your approach of putting libsys in
> the NEEDED section, or add it to the libc.so linker script, like what is
> done for libc++.so.
For dynamic library, this is wrong. libsys must not appear in the
dependency list of the final binaries, otherwise you break ABI and
old binaries which were not linked against libsys. This library only
contains private-namespace symbols, and should be not exposed to
applications. As was already mentioned, a filtering for the libsys.so
symbols in libc is good enough approach.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180403205920.GP1774>