[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171221213822.GY1627@brightrain.aerifal.cx>
Date: Thu, 21 Dec 2017 16:38:22 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Feature request: building musl in a portable way
On Thu, Dec 21, 2017 at 05:25:31PM +0100, ardi wrote:
> Hi,
>
> Related (and as an alternative) to a previous post I made asking about
> a way of isolating direct syscalls, I'm thinking about the possibility
> of building musl in a way where functions that need to perform
> syscalls aren't compiled, so this special compiled version of musl
> would have only the functions that don't make syscalls from
> themselves.
>
> The purpose is being able to run code in system other than Linux,
> replacing such functions by calls to the related functions of the
> system host (provided that functions follow POSIX requirements, of
> course).
>
> Obviously, I can get this feature by modifying musl, but I'd prefer
> not to modify it, because I'd like to be able to update musl to the
> last version easily, and if I use a modified/customized musl version,
> updating it would require merging, and possibly hard work.
>
> If there was some way of having a switch in the build system so that
> all functions that make syscalls are not compiled, I could use musl
> without modifying it. Maybe the most elegant way of doing this would
> be by tagging such functions with an special tag, like
> "__function_makes_syscall__" or whatever. But I'm not sure.
>
> Cheers, and thanks a lot,
I'm not clear what you want to do. A program that doesn't make
syscalls has no input except argv[] and environ[], does not terminate,
and has no output. So such a build of musl is certainly not useful as
a libc. Even if it were, configurable builds that exclude
functionality are intentionally outside the scope of musl; instead,
the project provides fine-grained linking so that you just get what
you need; ports to systems where some underlying functionality is not
possible simply need to make the relevant syscalls fail with ENOSYS.
With that said, my guess is that you're really asking for a way to
take the "pure" code out of musl and make it a library that you can
use on an existing C/POSIX (or non-POSIX C) implementation. This is
interesting, but currently outside the scope of musl, and probably
covers less interesting code than you might expect -- mainly:
- charset conversion (iconv, esp. utf-8 encoder and decoder)
- strstr
- qsort
- tsearch
- math (including complex, except complex isn't very good anyway yet)
- strtod family
- snprintf (but not usable independently of musl's stdio framework)
- mo file (gettext) lookup core (but frontend is not at all pure)
The rest of the pure code is almost entirely uninteresting, I think
(unlikely to provide any advantage over what's almost certainly
already present).
For now, the only way to use this code outside of musl is to copy it
(and possibly rename the identifiers if you need to avoid clashing
with the standard library on an existing system). Roughly half of the
above list are easy to do this with (no reserved-namespace
identifiers, single files or a few isolated related files, etc.) while
the rest have issues that make them invalid in application code
without nontrivial changes. Making it easier to use them outside musl
is an interesting problem but I'm afraid not one I have resources to
devote to at present..
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.
