From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4764 Path: news.gmane.org!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: MUSL_LIBRARY_PATH ? Date: Tue, 01 Apr 2014 12:27:05 -0400 Message-ID: <533AE8D9.8070309@midipix.org> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1396369651 11816 80.91.229.3 (1 Apr 2014 16:27:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2014 16:27:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4768-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 01 18:27:26 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WV1X3-0002gF-HX for gllmg-musl@plane.gmane.org; Tue, 01 Apr 2014 18:27:25 +0200 Original-Received: (qmail 26520 invoked by uid 550); 1 Apr 2014 16:27:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26510 invoked from network); 1 Apr 2014 16:27:24 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:4764 Archived-At: On 04/01/2014 10:11 AM, John Mudd wrote: > Possible dumb question... > > I built Python using musl. Not easy but it works. > > I also build libraries for Ncurses, Readline, Zlib, OpenSSL, BZip2 so > that all of that so the corresponding Python modules are working. Then > I installed setuptools and pip in Python. Then I used pip to download > and install several modules: Requests, ConcurrentLogHandlerand Psutil. > All using musl. > > I experimented with dynamic and static binding for the musl lib. I > lean toward dynamic because I may have a need for the "shared" version > of Python. > > So now I can run this on older machines. That helps me because I need > to deploy on old boxes. Upgrading the O/S is not an option. > > But I run into trouble when I start setting LD_LIBRARY_PATH so that > Python can locate the Readline and other libs. The musl built Python > works but these libs start causing native program to fail. e.g. "vim: > error while loading shared libraries: /usr/lib/i386-linux-gnu/libc.so: > invalid ELF header". In addition to setting LD_LIBRARY_PATH, you also need to set LIBRARY_PATH at build time, as well as verify that the executable contains the correct interpreter (loader) information. Two simple tests you could run are: 1) readelf -e /path/to/executable --> verify that the program interpreter listed under INTERP is the one provided by musl. 2) ldd /path/to/executable --> if LD_LIBRARY_PATH is improperly set, then ldd will either list the non-musl libraries, or completely fail. my guess is that LIBRARY_PATH was not properly set when you built your libraries, and that (1) will thus list the glibc loader (rather than musl's) as the "requested program interpreter." I hope that helps, zg > > And there's the ld-musl-i386.so.1 file in dynamic mode. I > specified --syslibdir=/tmp when I build musl so that's where I place > the lib. It works but I'd like more flexibility. > > I'm naive so my question is... how about a separate MUSL_LIBRARY_PATH > shell variable. Just like LD_LIBRARY_PATH but specific to programs > built using musl. That way I assume I could mix my musl Python with > native apps. > > As long as I'm asking, can MUSL_LIBRARY_PATH also specify where to > find ld-musl-i386.so.1? That might be crazy because a dynamic musl > program can't start without the lib so it can't interrogate a shell > variable? I'm still asking even though it might require magic. > > John > >