mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Ignoring dependencies libresolv and libcrypt
Date: Wed, 2 Sep 2020 12:42:52 -0400	[thread overview]
Message-ID: <20200902164251.GS3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <c69ba3b1-9ac2-9cf3-002e-764265dd69a1@arrikto.com>

On Wed, Sep 02, 2020 at 07:14:10PM +0300, Nikos Dragazis wrote:
> Hi everyone,
> 
> Apologies if this has already been answered before.
> 
> I am experimenting with musl. I see that musl produces a single DSO with
> all symbols, as opposed to glibc which produces multiple DSOs
> (libthread, libm, librt, etc.). I also notice that musl generates some
> empty archives for compatibility reasons, namely the
> lib{crypt,dl,m,pthread,resolv,rt,util,xnet}.a. These are already
> documented in the FAQ [1].
> 
> By looking at the code [2], I see that musl's dynamic linker ignores
> dynamic dependencies with names lib{c,pthread,rt,m,dl,util,xnet} and
> this makes sense based on the above.
> 
> What doesn't make sense to me is that musl's dynamic linker does not
> ignore dynamic dependencies with names libresolv and libcrypt. Is there
> a reason for this?

I believe the intent was only to reserve names that POSIX explicitly
reserves:

    If a directory specified by a -L option contains files with names
    starting with any of the strings "libc.", "libl.", "libpthread.",
    "libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the
    results are unspecified.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

However it looks like the sets don't entirely match up. I'm not sure
of the reason for the mismatch.

The set of "builtin" library names should probably be broken into two
parts: ones that will always be used (c, pthread, m, etc) and ones
that will be used as fallbacks if no file is found (resolv, crypt,
etc.).

Note that the purpose of these built-in names is twofold: (1) it's
part of glibc ABI-compat, for running glibc binaries with their names
in DT_NEEDED, and this role could be moved out with the gcompat
refactor if desired, and (2) supporting programs that (kinda
dubiously) use dlopen with these names to access standard
functionality.

Rich

  reply	other threads:[~2020-09-02 16:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 16:14 Nikos Dragazis
2020-09-02 16:42 ` Rich Felker [this message]
2020-09-03 10:47   ` Nikos Dragazis

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=20200902164251.GS3265@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).