From owner-freebsd-toolchain@freebsd.org Tue Apr 3 20:59:31 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D93FFF7FFCE for ; Tue, 3 Apr 2018 20:59:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3957B741A5; Tue, 3 Apr 2018 20:59:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w33KxK51071281 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Apr 2018 23:59:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w33KxK51071281 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w33KxK6u071280; Tue, 3 Apr 2018 23:59:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Apr 2018 23:59:20 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Brooks Davis , freebsd-toolchain@freebsd.org, Ali Mashtizadeh Subject: Re: splitting libc -> libc + libsys and static linking Message-ID: <20180403205920.GP1774@kib.kiev.ua> References: <20180403203210.GA23045@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:59:32 -0000 On Tue, Apr 03, 2018 at 10:39:44PM +0200, Dimitry Andric wrote: > On 3 Apr 2018, at 22:32, Brooks Davis wrote: > > > > We (mostly Ali) are working on a patch to to split the actual syscalls > > (__sys_) 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.