From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1368 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: empty lib*.a files Date: Tue, 24 Jul 2012 19:34:46 -0400 Message-ID: <20120724233446.GN544@brightrain.aerifal.cx> References: <500F0257.7010709@purdue.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1343206731 27560 80.91.229.3 (25 Jul 2012 08:58:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2012 08:58:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1366-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 25 10:58:46 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1StxQX-00027M-5f for gllmg-musl@plane.gmane.org; Wed, 25 Jul 2012 10:58:41 +0200 Original-Received: (qmail 11625 invoked by uid 550); 25 Jul 2012 08:58:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24450 invoked from network); 24 Jul 2012 23:35:04 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1368 Archived-At: On Tue, Jul 24, 2012 at 10:33:18PM +0200, Daniel Cegiełka wrote: > > musl puts everything in libc. The other libs are only present for > > compatibility with build scripts that are incapable of proper detection. > > They are, as it is said, intentionally left blank. > > > > With valediction, > > - Gregor Richards > > > > thx, we had a lot of problems with crypt_blowfish in libc vs libcrypt :) To clarify, the reasons all of the standard library is integrated into a single file mainly apply to dynamic linking: 1. Performance: Loading one shared library is faster than loading 3+ shared libraries. A modern multithreaded program is likely to use at least libc, libm, libpthread, and librt. 2. Saving memory: Each additional shared library wastes at least one page of commit charge and dirty physical memory, even though it will probably just be for the GOT except in libc which needs a few pieces of global data. Technically libm might be able to get by without a GOT entirely, but I doubt the linker would make a GOT-free library even if it technically could. 3. Avoiding exposing implementation internals and version incompatibility: If libc/libm/libpthread/etc. are separate libraries, they need cross-library references to implementation-internal functions and data. This in turn can lead to bad breakage if there's a version mismatch between them, and even worse, if a static version of libm or libpthread got used with a dynamic libc, the binary would now be permanently pegged to a particular version of libc due to using impermanent internal interfaces specific to that version. None of these issues apply if you're using static linking, but the reason I also chose not to split up the static library files is the same as the end of point 3 above: if libpthread.a contained static versions of the pthread functions, it might get linked into a program using dynamic libc.so, and introduce the version lock-in described above. To avoid this, we'd have to make sure a file named libpthread.so existed as a no-op linker script (if it existed as an empty ELF shared library file, it might get added to the program's DT_NEEDED and then points 1 and 2 above would apply). Since there's no benefit to separating the standard library into broken-down .a files, and lots of potential pitfalls, I chose not to separate it for static linking either. As for why the empty .a files exist, it's because POSIX requires -lm, -lpthread, etc. to be valid options to the C compiler, and requires portable programs to use these options in their build scripts even if the implementation does not require them. Making empty .a files is the easiest way to meet that requirement. Rich