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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 4115 invoked from network); 21 May 2020 15:21:36 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 May 2020 15:21:36 -0000 Received: (qmail 22013 invoked by uid 550); 21 May 2020 15:21: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 21995 invoked from network); 21 May 2020 15:21:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590074482; bh=7EsUv5Pa2XAaeZZupwOLOz8MqUJFqWS4Zyi54I0d8qQ=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=WEluNhnUkfijj3u6LSdGAJFinop5NKz/xUbAtd3iZOQKGaMHY7SKtwc6o3qdvHqqX I/hjHkXdcREp7CppMHaezNF1iIke1x6atDf7Opvt/ZxRKSQ8idk00l9B8x16Yym7os n7VUbpB2nMcLEGsZq6kyjtgx4RNCWctGDPnwRGLQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Thu, 21 May 2020 17:21:21 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200521152121.GA6521@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:V8WqcLiIM/Ry0oRGvAmNfNQ5NTM+YdlE1l14CoBikRSxakfY3g+ 39T0RO1vf3Kf9cvGSj7Pfe34Cz6Q6BM3IazZUXXB4ciYEfank01y8QPnxl03MnoRm6P6QC5 Bi+nwg5oZr/sPdQJ1wzLdn6u/w5csWLA2KrPkWltfUKXOimkSkNvc0E5bjOW1BB4sx+vPza 9Lmcs9aiB7lqdc/k9R8pA== X-UI-Out-Filterresults: notjunk:1;V03:K0:csRgknJkvbk=:Pogaw9A+GUox4+9ZgKa9Ro GhJKg4aKOEZsJIyhanyVce8LrAY6zxx49T17O7gyJwLRIFOShosH0aYRZ2n1MkX5SmWKGCMBW pXi9C6Qg/TOcPG5Z1a3TgfOe1fxLxfdubtuSJv65qhttPaTHMl6ybA/fW+JJFA6NsZJqlQweo RzXjQlkbmd7bCzCwZRfpUoKbYeVC45u3CtygKjiYKArJ9rHRTp9LLLZXvucIgvMx+pNEMrZC5 sB1PRUXFS0judl5uDV/xD2ul6sEzbxCSuQANuOTqEKN3ascEznVEA14CWu6YZFORWVovM+dKN iIyykOHAePgzUIY3PoaywrwSTqjwn48FRwt88wIPzJVpbMgbRF0YMkq+AoUuDQRtof74lvxBy KYHI2n4LKFdM98WB7KX+isvBNRLDZqQsH5LpikSvyG5HcjE3JfniXbQnMiPp2Z6LXrumDUB5c uPR8fk+3JAgwf34CqXbkt8wDWhTKsGulXF8ZhseFa3dHPrKx7LQ3nG7o23TNZcFVU/JbtP+cY UVBY8cy+GwKodt72CwCN6yD30wGUqQ3GRp9ufeydDEAYbsqMtFDfiuSPv753C0Ru/rAcuv11C ImWp3HoE/FtHyVsOwl9EPqAQHbNHRfrnnLvix0I9ki+78+jhu5w60mssRvQWwFWlCByhKCdXI +JI+OfOcIBmDKxoY8k6xJoEAdg2Oa8qZVAetiR21Stny4I+juHNSGo2O2ZEvlBRa4D5XC591K H5Ryj677JkPPzmS5xM1KBQvRN3VdT9M1tAq/jE2gwsR9FhqNUK+iDFQT0jlZm4y2HW0WJO/p6 MS1VsiGOUuIJtNO3pta0mTzP53K7wQ44/zF/FhlOuyzCR7K954uTXiLdHCSAdkRmtxoODx32X aJ4IJALyeUBEHsE5m1CNbm95iU436LShwaiGCv2JDmlmFbfuBU1oUaGE5EJsun5/onRz/jqKl RAAFEaQ7HhII4cpUpMPPwTc6FSYPVWi2loOTIB5OJWqNNuiYpJBBOK7jirRspjVnz9Wzq/5ky XTskTNdVJe4pgbQyoawceHKaevdwHxMUKzfCeOSDsyDiGOLcpDPlh80HILvEBxllNfR1uzU2a exr+1VNkCFdOopJGOw/EtXwhQwEmw+aXO2V+hWud7m0OTlK3FHlR65wgi3QLr73b2Irpv5TTj NvqReN3nGd/vLPGy0OTIimufrMmOhd2O7dbP6EGAAMof9Qazwv0rqglFRkWnB6CoZmeFOHQxv toPYWdWvBGqLddELr Subject: Re: [musl] Shared library loading 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 o= wn > 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=A0 flag "RTLD_LAZY". > > The "b" library loading works on my Ubuntu 19.10 and fails on Alpine 3.1= 1.6 > with message: > =A0 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 !=3D name) p->shortname =3D strrchr(p->name, '/')+1; 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