Is there any plan for a dependency-free subset of "core" runtime?
Zheng Luo (Vic)
vicluo96 at gmail.com
Thu Jul 19 12:40:09 UTC 2018
On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote:
>
> Well, since 2.079 it's actually possible to use D without a
> dependency any runtime (even libc):
>
> https://dlang.org/changelog/2.079.0.html#minimal_runtime
>
> Also with -betterC you can actually use lots of things from
> core that don't depend on the runtime. For example,
> std.algorithm/range works in betterC:
>
> https://run.dlang.io/is/38yowj
>
> Now, I assume you are asking whether there are plans for a
> minimal -betterC runtime?
> There aren't "official" plans, but AFAICT a few people are
> independently working on this. It might be a good idea to join
> efforts with them.
Thank you for the clarification. I am working on a libc-free
project (SAOC project: 2D rasterizer on embedded devices) and
just faced some missing symbols(__assert, _memset32) from various
libraries in snippets like https://run.dlang.io/is/Kme62V (more
missing symbols without C runtime). I am a little bit confused at
the boundary of D components:
- which subset of standard library can be used under -betterC?
- even with -betterC, the compiler sometimes require external
symbols like __assert to work, so what are all the required
symbols? rust-core limits them to five: memcpy, memcmp, memset,
rust_begin_panic and rust_eh_personality.
Is there any way to make this project remain as a "library" with
a few explicit external symbol dependencies instead of bundling a
minimal d-runtime/libc stubs? Since eliminating d-runtime looks
like an overkill in the most of time (almost every embedded
project defines their own size_t/string/bitop/attribute, hope to
see a core subset of d-runtime to prevent reinventing the wheel.
More information about the Digitalmars-d-learn
mailing list