Re: MUSL_LIBRARY_PATH ?

["writeonce@midipix.org" <writeonce@midipix.org>]

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
>
>