mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Ignoring dependencies libresolv and libcrypt
@ 2020-09-02 16:14 Nikos Dragazis
  2020-09-02 16:42 ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Nikos Dragazis @ 2020-09-02 16:14 UTC (permalink / raw)
  To: musl

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?

Thanks in advance,
Nikos


[1] https://wiki.musl-libc.org/faq.html#Q:-lib(m|pthread|crypt).a/so-are-empty?
[2] https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n991


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Ignoring dependencies libresolv and libcrypt
  2020-09-02 16:14 [musl] Ignoring dependencies libresolv and libcrypt Nikos Dragazis
@ 2020-09-02 16:42 ` Rich Felker
  2020-09-03 10:47   ` Nikos Dragazis
  0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2020-09-02 16:42 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Ignoring dependencies libresolv and libcrypt
  2020-09-02 16:42 ` Rich Felker
@ 2020-09-03 10:47   ` Nikos Dragazis
  0 siblings, 0 replies; 3+ messages in thread
From: Nikos Dragazis @ 2020-09-03 10:47 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 2/9/20 7:42 μ.μ., Rich Felker wrote:

> 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.).

It's not clear to me how the second part could be useful. Also, it would
break the scenario where one wants to use musl to run a glibc-compat
executable on a glibc-based system, because the linker would load
glibc's libresolv.so.

>
> 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

Then definitely resolv and crypt should be part of it.

> , 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-09-03 10:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-02 16:14 [musl] Ignoring dependencies libresolv and libcrypt Nikos Dragazis
2020-09-02 16:42 ` Rich Felker
2020-09-03 10:47   ` Nikos Dragazis

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git