|
Message-ID: <533AE8D9.8070309@midipix.org> Date: Tue, 01 Apr 2014 12:27:05 -0400 From: "writeonce@...ipix.org" <writeonce@...ipix.org> To: musl@...ts.openwall.com Subject: Re: MUSL_LIBRARY_PATH ? 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 > >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.