[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
