From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27708 invoked from network); 2 Sep 2020 16:43:09 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Sep 2020 16:43:09 -0000 Received: (qmail 13730 invoked by uid 550); 2 Sep 2020 16:43:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13704 invoked from network); 2 Sep 2020 16:43:05 -0000 Date: Wed, 2 Sep 2020 12:42:52 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200902164251.GS3265@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Ignoring dependencies libresolv and libcrypt 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