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=-4.1 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12423 invoked from network); 3 Sep 2020 10:47:24 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Sep 2020 10:47:24 -0000 Received: (qmail 30542 invoked by uid 550); 3 Sep 2020 10:47:19 -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 30521 invoked from network); 3 Sep 2020 10:47:19 -0000 To: Rich Felker References: <20200902164251.GS3265@brightrain.aerifal.cx> From: Nikos Dragazis Cc: musl@lists.openwall.com Message-ID: <373428ae-522f-0747-eab1-ecbb6df3c359@arrikto.com> Date: Thu, 3 Sep 2020 13:47:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200902164251.GS3265@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [musl] Ignoring dependencies libresolv and libcrypt 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