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=DKIM_SIGNED,DKIM_VALID, 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 9890 invoked from network); 22 May 2020 18:07:35 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 May 2020 18:07:35 -0000 Received: (qmail 17787 invoked by uid 550); 22 May 2020 18:07:33 -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 17766 invoked from network); 22 May 2020 18:07:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell-sw-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=2kSqATGGDX5LmlCUlUIHBvaaC4crcjCRKdTwhfrzz+k=; b=stldNxXenmH7IXAbOSlMHEiYWBMdfqRIY2NYpc09j8/LERq2Qt5+WqYVrdfSRkps9W XK34f/letnlhCl4fm6QHB6R36VGr8o9e5oom38YyKgTDultSptNffmNL354TRcMmVcyG Lxa/LDJxawe9uFm2CH6YXvw2gR0rsGmURxXNJz+fpGF63XIccWGYgkNXe2ifejOx+5UR dVPip7SOFM6D1o3Jhy5dM34uMN6P6BiKyZY6rF6BFvDCYnTyT2cbskZ7P8FjyFlyJPX6 AwCc8AouFxThPnVciQBbG0IeKadsQcRp+vQLveE5JrpN3nQ2Jc5qMgY/df9iipP4IoYP JpHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2kSqATGGDX5LmlCUlUIHBvaaC4crcjCRKdTwhfrzz+k=; b=Cj/J6FFQhWwcjgUGWsIXNt+NNley9F2TSs6dAyIic8Qf8YBtdM9kMCVERJGui2wJkf k3K8KVoJFJNOqu6DfjmCG5DYPjjD2+zStt2VNKe6Bwet1VxZA5P5BpKDjy+uhrimlr/B /sry6XSrZtDiidc5B17FxcsjV//Yhfzx/3DQOPA+8eqwA0VGk1Grs8Q5dFmdG7oKByoZ O6v/r/LK7Di6+zBwpr7ZRucSmY3/4e+3C0+8R2XvulYMRrsyXRIjFG/qBNEZs4q3xdNJ XGRWKgpNfJxCcftZNBVaceBuA2YF6fbDUoAae6h/IcIwzJb0Lw/PplHVgbptxNd/G5sS tz/Q== X-Gm-Message-State: AOAM533dAFVwM1R/9L+GtAo74n7CMaKnF/pI4ZP3Nna8LwBDPbgBsSj3 /l+QHh+PZIrX1mls/GwdRe6BFEmLlsg= X-Google-Smtp-Source: ABdhPJy5Rr7Bcm+e9oahnU5ezh1hLLGv6SI96AF5eW7v8U9dNWfAVy2nCj3dmBurGCMo2SyGaN4lhA== X-Received: by 2002:a05:651c:1207:: with SMTP id i7mr7905192lja.86.1590170841573; Fri, 22 May 2020 11:07:21 -0700 (PDT) To: musl@lists.openwall.com, Markus Wichmann References: <20200521152121.GA6521@voyager> From: Alexander Scherbatiy Message-ID: <883535a2-1b26-183d-22f4-c3c158da2dbb@bell-sw.com> Date: Fri, 22 May 2020 21:07:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200521152121.GA6521@voyager> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [musl] Shared library loading On 21.05.2020 18:21, Markus Wichmann wrote: > On Thu, May 21, 2020 at 02:27:24PM +0300, Alexander Scherbatiy wrote: >> Hello, >> >> I use Alpine Linux 3.11.6 with musl libc (x86_64) version 1.1.24. >> >> I have two shared libraries "a" and "b" each of which is placed in its own >> directory and lib "b" depends on "a". >> First, I use dlopen to load lib "a" with "RTLD_NOW | RTLD_GLOBAL" flags. >> Second, I load lib "b" with  flag "RTLD_LAZY". >> >> The "b" library loading works on my Ubuntu 19.10 and fails on Alpine 3.11.6 >> with message: >>   dlopen failed: Error loading shared library liba.so: No such file or >> directory (needed by /root/load-lib-sample/bin/b/libb.so) >> Should it work on Alpine with musl libc as well? > [...] > > I shall leave the "Should it work" to others who know more about this > than me. But I will tackle the "Why doesn't it work". It appears however > the behavior is intentional (whether the consequences are as well > remains to be seen). Namely in line 1140f. of dynlink.c (revision > 72658c65): > > > |/* Add a shortname only if name arg was not an explicit pathname. */ > |if (pathname != name) p->shortname = strrchr(p->name, '/')+1;   It would be interesting to know which task this check is supposed to solve.   Thanks,   Alexander. > > This means, in your case, the DSO handle for liba does not get a short > name, so when libb is loaded, it is not detected that liba has already > been loaded (only the shortname is used for that purpose). And since > your files are in different directories, liba is also not found to be > loaded again. To work around this, you can set LD_LIBRARY_PATH to the > directory containing liba. In that case, when loading libb, the > dependency will be found with the environment search, and since liba was > already loaded, the loop in lines 1085ff. will find the handle and even > assign a shortname. The shortname is only used for checking of > duplicates. > > Ciao, > Markus