[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161009160851.GC19318@brightrain.aerifal.cx>
Date: Sun, 9 Oct 2016 12:08:51 -0400
From: Rich Felker <dalias@...c.org>
To: Bobby Bingham <koorogi@...rogi.info>
Cc: musl@...ts.openwall.com, John Mudd <johnbmudd@...il.com>
Subject: Re: Re: 32 bit musl?
On Sun, Oct 09, 2016 at 10:10:36AM -0500, Bobby Bingham wrote:
> On Sun, Oct 09, 2016 at 04:44:44PM +0200, Szabolcs Nagy wrote:
> > * John Mudd <johnbmudd@...il.com> [2016-10-09 10:29:02 -0400]:
> > > On Sat, Oct 8, 2016 at 9:55 PM, John Mudd <johnbmudd@...il.com> wrote:
> > >
> > > > Rich's musl-cross-make builds 32-bit executables that use musl libs. It
> > > > kills two birds with one stone. That's great.
> > > >
> > > > But it appears to expect musl libc to be installed in /lib for dynamically
> > > > linked executables. That's not an option for me. Is there a way I can
> > > > override this?
> > > >
> > > >
> > > Thanks Laurent, I used symbolic link in /lib for testing on my development
> > > machine. That works well. But I don't have reasonable access to root user
> > > when I deploy for production.
> >
> > deploy static linked binary or use explicit -Wl,-dynamic-linker
>
> Using -Wl,-dynamic-linker will result in binaries that will not run on
> normal musl systems.
It will also result in binaries that require the end user to have them
(or at least the dynamic linker part) installed in exactly the same
absolute path that you came up with when building them.
> If you can deploy the musl libc alongside your program, you can invoke it
> as `/path/to/libc.so /path/to/your/program`. This can be done by a shell
> script you also deploy.
Indeed, this is the recommended approach for shipping dynamic-linked
binaries to be run on non-musl-based systems.
Rich
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.
