mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: empty lib*.a files
Date: Tue, 24 Jul 2012 19:34:46 -0400	[thread overview]
Message-ID: <20120724233446.GN544@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAPLrYETX4=58YrVB226ht44pGE4PpTkLAaDPKoAC52jpqASOXQ@mail.gmail.com>

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


      reply	other threads:[~2012-07-24 23:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 20:11 Daniel Cegiełka
2012-07-24 20:15 ` Gregor Richards
2012-07-24 20:33   ` Daniel Cegiełka
2012-07-24 23:34     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120724233446.GN544@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).