Import Glibc on Embedded

Platform Embedded
1

Hi! The following PR introduced importing WASILibc from Embedded, which is great!

It’s also possible to import Darwin on macOS Embedded.

Is something similar planned for Glibc on Linux?

2

Not as far as I'm aware of, but IMO creating one for Musl would be much more interesting, and possibly less work, since WASI-libc is a fork of Musl. Also would probably make it easier to distribute it as a part of the existing Musl Swift SDK.

2 Likes
3

Thanks @Max_Desiatov! It’s not the answer I expected, but then I realised I’m actually asking the wrong question.

What I’m actually interested in is a sanctioned way of accessing what’s already available but cumbersome without hacks or workarounds (extern / c headers via an additional module). In this case I just mean some basic math functions like sin, log, exp, etc. So actually I can probably just use Swift Numerics. Beyond that I guess it’d be asking too much for things like Clocks in Embedded mode.

I can’t think of much else I’d need regularly from Glibc beyond what’s available in Swift System (not sure that’s available on Embedded + Linux yet though).

I think I understand why these libraries are libraries and not part of the language itself (even though Numerics simply uses Builtin for most of its functionality – that does feel particularly weird to me, because it seems like Swift cannot be built without these functions, but doesn’t expose them by default?). That said, it does feel to me like a bigger hurdle than I’d like to add a package from the internet to use e.g. basic math – I can’t think of any other language where this is the case.

While we do of course also download toolchains and SDKs from the internet, they feel like more part of the system because they’re not removed along with the .build directory.

That’s why I posed the question I think – I’m looking for built in access to basic stuff. I was happy that WASILibc provides what I was after here, but thinking about it more, I think my request touches on something more fundamental. Maybe it’s just a request to move Numerics (and maybe System for that matter) into the stdlib?

Thank you as always nonetheless for your quick and informative response!

2 Likes
4

You can import Darwin in Embedded Swift:

$ cat foo.swift
import Darwin

@c func main() -> CInt {
  var s = stat()
  stat("foo.txt", &s)
  print(s.st_dev)
  return 0
}

$ swiftc foo.swift \
  -parse-as-library \
  -enable-experimental-feature CDecl \
  -enable-experimental-feature Embedded \
  -wmo 

$ ./foo
0

tested with the "main 10/17/25" toolchain

2 Likes
5

Yes, that is what Geordie said too:

1 Like
6

@scanon it’s been a few years since the initial release of Numerics. My understanding was that the library format would allow faster iteration without needing an evolution process to do so. That makes sense, but my impression is that the core of the library is extremely stable.

Is there any scope for pitching at least the Integer and Real modules for integration into the stdlib? Or at the very least a stable subset of them?

1 Like
7

Bringing the Real functions from Numerics into the stdlib would be source-breaking (due to the ambiguity with static member functions vs global functions that originally prevented us from being able to land SE-0246 when it was accepted). At the time, we thought that ambiguity was something that we’d be able to “fix”, but it seems now that we may be stuck with it.

There’s also been a flurry of work recently on fast correctly-rounded transcendental functions in the llvm libc, the core-math project, and the Rutgers libm project, among others. This puts having a math library that gets correctly rounded results (and therefore portable results across language versions, OSes, and hardware) with only modest performance penalty within striking distance. My goal would be to land only correctly rounded implementations in the standard library when they move there, such that (up to bugs, which are hopefully rare), any stdlib transcendental functions would always deliver the same results everywhere. So I’ve been waiting for some of those efforts to mature a bit before re-proposing something.

8 Likes
8

Is there somewhere I can read about this work?

9

Both the Rutgers and CORE-MATH teams are academic-led and are quite good about writing up what they’re doing.

2 Likes
10

Thanks

12

Thanks, I didn’t realise what I suggested had actually already happened and even been accepted. The static overloading issue does make sense to me, but I don’t really understand why it isn’t fixable. I do feel like this could be an „upcoming feature” though available for opt in. It seems unfortunate that source compat means this doesn’t happen at all.

I think what you’re suggesting is something like that could be pitched in future but you’d like to wait for the standardisation and implementation of the correctly-rounded transcendental functions before doing so. I must say I’m curious why we’d need to wait assuming the correctly rounded versions are implementation details? Or do you expect the public API to also change for some of them?

Thank you!