[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFipMOFePtrSPAL4tKysX9Tg+ezGdhzWj0KDnPvAh=XhkpV4VA@mail.gmail.com>
Date: Wed, 27 Mar 2013 10:23:46 -0400
From: LM <lmemsm@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Will musl work as a lsb alternative? (was Re: re:
musl setup attempt)
On 3/26/13, Isaac Dunham wrote:
> On Tue, 26 Mar 2013 19:03:28 -0400
> Rich Felker wrote:
>> Could you elaborate on what you mean by "sticking with LSB"? LSB is a
>> specification for ABI, filesystem layout, etc. -- basically, what apps
>> can expect from a "Linux system" -- not really a tool in itself.
> Rich:
> There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce binaries
> that use the LSB ABI and are portable so you don't need to worry too much
> about glibc symbol versioning, etc.
That was what I was referring to, using the lsbcc, lsbc++ compilers.
Isaac Dunham wrote:
> If you don't want to ship any/many libraries and fully static binaries are
> not an option, using lsbcc is your only option. That does require the target
> distro to provide LSB support, which is widespread but certainly not
> universal.
Have no problem with including the libraries.
> If you want binaries that can run _anywhere_, static linking with a generic
> build of musl will work well (x86 musl compiles for i486 by default,
> although you can change the minimum processor by setting CFLAGS to
> -march=...).
i486 default should be fine for my needs. Target systems will most
likely be i486 and up.
Rich Felker wrote:
> If you don't need threads or new (mainly POSIX-2008) features, musl
> should work even on 2.4 kernels. Of course, 2.4 kernels have a number
> of bugs and conformance issues, especially in signal handling, which
>apply regardless of which libc you are using.
Thanks. Will keep this in mind.
Isaac Dunham wrote:
> LGPL (requires distributing application source code or object file so customers
> can relink), and slightly larger. Don't think about a uclibc shared binary
> if you want portability; that way lies madness.
The project I'm working on will include source code for all Open
Source applications in it. I'm trying to work out a way to do
something like OpenDisc's educational CD and offer a Linux version
with lightweight Open Source applications. Was hoping to avoid
shipping a whole Linux distribution (live CD) just to try out using
the programs. If the programs don't work on a particular system,
someone could always rebuild from source if necessary. Most (but not
all) users seem to prefer having the binary, not just the source code.
Not everyone wants to build everything from scratch just to try it
out. Was thinking of setting the applications up to work somewhere
under the home directory so administrative rights would not be as big
of an issue.
>> it is possible to use the path/to/libc.so <command> trick or an ELF
>> editor to circumvent this. Currently, you might want to include most
>> of the libraries if you go for this.
>Yes, you could definitely do this with a shell script wrapper too. It
>would work a lot better if we added command line options to the
>dynamic linker...
I was thinking about that as a possibility. Definitely sounds like
I'll need all the libraries. The applications are mainly command
line, SDL, FLTK and curses based. Command line and curses shouldn't
be a problem. SDL has a DirectFB option which may work for some
users. FLTK usually requires X Windows (although there's an older
version that has a port to DirectFB that might be worth
investigating). Am wondering if I can build the X libraries from
scratch with musl, if they'll interact with the host system's X server
or if a user would need to exit their X server and use a musl built X
server and X libraries.
PCBSD does some packaging (on the style of a wrapper script) where
they set things like LD_LIBRARY_PATH before running the application
and reset it back to a default environment after the application runs.
Was thinking if I can avoid the rpath switch when building the
applications, I might be able to make use of a technique similar to
that.
Rich Felker wrote:
>I think it would still be a very interesting exercise to make some
>tools to put ld-musl.so inside the program binary, so that you could
>have a binary that does not depend on any particular dynamic linker
>path.
That sounds like a very interesting idea.
Thanks to both of you. You've given me a lot to think about and start
experimenting with.
Sincerely,
Laura
http://www.distasis.com/cpp/
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.
