From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12270 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Feature request: building musl in a portable way Date: Thu, 21 Dec 2017 16:38:22 -0500 Message-ID: <20171221213822.GY1627@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1513892200 21091 195.159.176.226 (21 Dec 2017 21:36:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 21 Dec 2017 21:36:40 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12286-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 21 22:36:36 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eS8W4-00056t-4F for gllmg-musl@m.gmane.org; Thu, 21 Dec 2017 22:36:36 +0100 Original-Received: (qmail 13448 invoked by uid 550); 21 Dec 2017 21:38:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13419 invoked from network); 21 Dec 2017 21:38:34 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12270 Archived-At: 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