Stream: general

Topic: bits/errno.h


view this post on Zulip Vedant Roy (Sep 14 2020 at 23:47):

I'm trying to use wasm-libc to compile the gnu coreutils for the web (with poyfills/shims where necessary). I noticed that bits/errno.h is not inside of the wasm-libc headers. I'm pretty new to systems programming, but is this because that header is specific to GNU libc? I thought this might be the case, but i see musl libc also includes bits/errno.h. Apologies if this is too much of a unix question, and not enough of a WASM question!

view this post on Zulip Dan Gohman (Sep 14 2020 at 23:54):

Yes, "bits/*" is non-standard.

view this post on Zulip Dan Gohman (Sep 14 2020 at 23:54):

For most purposes, the standard path <errno.h> should work.

view this post on Zulip Dan Gohman (Sep 14 2020 at 23:59):

It's a little surprising GNU coreutils would use bits/*, as it's meant to be portable across Unix-type platforms

view this post on Zulip Vedant Roy (Sep 15 2020 at 00:02):

I don't think GNU utils is using bits, rather, I'm using the __wasilibc_unmodified_upstream option, which is causing bits/* headers to be included

view this post on Zulip Vedant Roy (Sep 15 2020 at 00:05):

Thank you for the help -- I think what I'll do is not use the unmodified_upstream version. I need to know which unix functions are undefined in wasilibc anyways, so I can polyfill them with Javascript.

view this post on Zulip Pat Hickey (Sep 15 2020 at 00:06):

thats not an option which is intended for use

view this post on Zulip Pat Hickey (Sep 15 2020 at 00:06):

in the early days it was used to help us track differences from upstream so we could merge in changes from upstream musl

view this post on Zulip Pat Hickey (Sep 15 2020 at 00:07):

we no longer use it for new changes, because the shape of many of the changes we've made has made it too noisy to mark them in this way, and at one point we discussed deleting it throughout leaving only the modified code left, but it was never a priority

view this post on Zulip Dan Gohman (Sep 15 2020 at 00:27):

Yeah. In particular, __wasilibc_unmodified_upstream is guarding declarations that aren't supported by the actual libc code, so even if you do define it, you'll get link errors if you try to use those declarations.

view this post on Zulip Vedant Roy (Sep 15 2020 at 00:29):

I knew as much -- the plan was to write C/JS polyfills for all the non-implemented functions (or at least the ones I needed to run coreutils). Specifically, I was using the -Xlinker --allow-undefined option to generate wasm imports for everything that was undefined.

view this post on Zulip Dan Gohman (Sep 15 2020 at 00:35):

Ah, the current codebase doesn't anticipate being used like that, so you're in uncharted territory!

view this post on Zulip Vedant Roy (Sep 15 2020 at 00:36):

oh well, that's where all the interesting stuff happens :)


Last updated: Nov 22 2024 at 16:03 UTC