Re: Is there any plan for a dependency-free subset of "core" runtime?

[Zheng Luo (Vic) via Digitalmars-d-learn]

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.

Is there any plan for a dependency-free subset of "core" runtime?

[Zheng Luo (Vic) via Digitalmars-d-learn]

Current implementation of d-runtime relies on a lot of symbols 
from libc, librt, libpthread, which makes it hard to create a 
minimal runtime used for embedded devices. Although there are 
some unofficial minimal versions of d-runtime, many of them lack 
maintenance and outdates rapidly. I was wondering that is there 
any plan for a https://doc.rust-lang.org/core/ library in D 
world, which only depends several explicitly-defined symbols?

names not demangled in nm --demangle=dlang

[Zheng Luo (Vic) via Digitalmars-d-learn]

Hi,
I built a simple program with dmd a.d and tried to observe 
symbols with nm --demangle=dlang ./a. However, I can observe that 
only part of the symbols (e.g., std.stdio.File.size()) are 
demangled, while others remain in their original name (e.g., 
_D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? 
Moreover, what is the suggested way to demangle symbol names in 
dlang?


Thanks