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