[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0502MB3885E01DBE6F99A0F36C39B9E7020@VI1PR0502MB3885.eurprd05.prod.outlook.com>
Date: Fri, 22 Dec 2017 17:10:20 +0000
From: Nicholas Wilson <nicholas.wilson@...lvnc.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Feature request: building musl in a portable way
On 22 December 2017 16:09, ardi wrote:
>> On Thu, Dec 21, 2017 at 10:38 PM, Rich Felker <dalias@...c.org> wrote:
>> I'm not clear what you want to do.
> I'm looking for a C runtime with a MIT-like license that can be
> compiled for several architectures, in 32bit and 64bit, mostly Intel,
> PowerPC, ARM, and MIPS, and is endian-safe, and written in a tidy
> code. I need that such runtime is able to be retargeted to different
> OSs by changing the layer where syscalls are made. At the moment of
> writing this, the OSs I'm interested in are Linux and MacOS. In the
> future I'll likely be interested in other OSs as well.
> I don't know of any C runtime that meets all these requirements. The
> only two that get close are the different BSDs C runtimes, and musl,
> but both lack the last requirement (i.e.: syscalls are not
> encapsulated in some confined files so that you could rewrite such
> "syscall layer" for each OS --instead, syscalls can be issued from any
> place in code, and the only way to locate and encapsulate the proper
> functions is to manually search for invocations of syscalls in the
> source tree).
This still doesn't explain what you want to *do* - this explains what you *want* but not how you're intending to use it.
If you want a libc for MacOS, I would suggest using Apple's libc. On Linux, you may want to use glibc (or Musl, on distros that have chosen that).
As you've discovered, a libc implementation is tightly coupled to the OS - in a sense it really is a component of the OS itself. Writing a libc that targets different kernels would quite an undertaking, but possible - but of much more importance are the "upwards" dependencies. You're thinking about "how many kernels can a libc support", but of more importance is, "how many platform ABIs can the libc support upwards". For your hypothetical libc that runs on Linux and MacOS, do you want it to be usable on MacOS with applications compiled against Apple's headers, and usable on Linux with applications compiled against glibc's headers? That's just as much a challenge, and would be perhaps the major reason no-one's tried to create a "universal" libc: established applications use slightly different ABIs on each platform. If you want to call into any MacOS userland functionality, you'll need to have a libc that's fully ABI-compatible with those MacOS components.
If you insist on using Musl on MacOS, your route forwards would be to implement the Linux syscall ABI using MacOS syscalls, effectively emulating Linux on each platform where you want to run Musl.
That's how we're using Musl on WebAssembly. Musl uses Linux syscalls, so we implement Linux syscalls to keep Musl happy.
Nick
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.
