On Thursday, 12 November 2020 at 06:42:00 UTC, Jacob Carlborg wrote:
> Unfortunately it won't be that simple for D. D took the easy way out and relies both on the C standard library and other platform specific libraries implemented in C. While it's easy to cross-compile and object file, linking will not be as easy.

FWIW I started working on some stubs for a pure-d libc a while back - https://github.com/moon-chilled/dlibc/.  If it were completed and integrated into druntime--or, at least, if enough of it were completed to support druntime+phobos--then it would make for a much nicer cross-compiling experience.


> Also, on macOS they're cheating. Because they cannot ship the SDK, they solve the linking problem by allowing undefined symbols. I don't know if Go does the same.

Perhaps a better solution would be to link to a stub dylib of libc?  (Assuming macos libc has a stable ABI.)


> There's LLD, which works on Windows and Linux, but it doesn't work for macOS.

As of about a year and a half ago, its status was

> LLD for Mach-O has bitrotted significantly and isn't really functional anymore (beyond the most basic programs). I'd recommend sticking with ld64 as the linker.

(From http://lists.llvm.org/pipermail/cfe-dev/2019-March/061666.html)

so the situation may have improved in the mean time; looking at the logs (https://github.com/llvm/llvm-project/commits/master/lld/MachO) I see a fair amount of activity.  (In particular, commit 2e8e1bd adds support for stub dylibs, relevant to my above proposal.)

On Thursday, 12 November 2020 at 18:58:56 UTC, Elronnd wrote:

> FWIW I started working on some stubs for a pure-d libc a while back - https://github.com/moon-chilled/dlibc/.  If it were completed and integrated into druntime--or, at least, if enough of it were completed to support druntime+phobos--then it would make for a much nicer cross-compiling experience.

That's nice. But I would prefer if druntime and Phobos did not depend on the C standard library, even if it's implemented in D. You're constrained by C and by the API of the C standard library. Implementing druntime and Phobos without the C standard library will give a big opportunity to do things better.

> Perhaps a better solution would be to link to a stub dylib of libc?  (Assuming macos libc has a stable ABI.)

That's already what I'm working on [1].

>> LLD for Mach-O has bitrotted significantly and isn't really functional anymore (beyond the most basic programs). I'd recommend sticking with ld64 as the linker.

Same here, working on that as well [2].

[1] https://github.com/d-cross-compiler/sdk-apple/releases/tag/v0.0.1
[2] https://github.com/d-cross-compiler/cctools-port/releases/tag/cctools-949.0.1-ld64-530

--
/Jacob Carlborg

On 12 Nov 2020 at 07:42:00 CET, "Jacob Carlborg" <doob@me.com> wrote:

> The reason why it works for Go is because they have their own full toolchain. That means, their own compiler (including backend), their own assembler, their own object format and their own linker. All of these are written to be cross-target.

And being x-target is a key design goal, which is really an amazing out-of-the-box experience.

Of course you have some (silent) different behavior for some Go std lib stuff... which can be of surprise. The rust guys take a much more pedantic approach here, which IMO is the cleaner way to do it.

However, Go's goal is getting stuff done. And it's really delivering on that.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On 11/12/2020 11:15 AM, Jacob Carlborg wrote:
> Implementing druntime and Phobos without the C standard library will give a big opportunity to do things better.

How so? (Not that you're wrong, I'm just genuinely curious.)

On Friday, 13 November 2020 at 03:33:05 UTC, Walter Bright wrote:
> On 11/12/2020 11:15 AM, Jacob Carlborg wrote:
>> Implementing druntime and Phobos without the C standard library will give a big opportunity to do things better.
>
> How so? (Not that you're wrong, I'm just genuinely curious.)

It might not necessary mean a better or different API for Phobos. But the lower level APIs could be better.

Classic examples are:

* Use arrays instead of pointers (or pointer length pair). `memcpy` would be:

void[] memcpy(void[] source, void[] destination); // I think it's more natural to pass the source first

* Better error handling. I think returning error codes or using `errno` is pretty bad error handling strategy. Even though exceptions might not be the right choice (unless something like this is used [1]), something like returning: `Result!(Value, Error)` might be better.

* No global symbols, i.e. not having to worry about conflicting names across multiple files

In short, all the reasons for which you created D in the first place ;)

Unfortunately there will still be some limitations due to how the kernel APIs use pointers and error codes/errno.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

--
/Jacob Carlborg

On Saturday, 14 November 2020 at 19:19:02 UTC, Jacob Carlborg wrote:
> On Friday, 13 November 2020 at 03:33:05 UTC, Walter Bright wrote:
>> On 11/12/2020 11:15 AM, Jacob Carlborg wrote:
>>> Implementing druntime and Phobos without the C standard library will give a big opportunity to do things better.
>>
>> How so? (Not that you're wrong, I'm just genuinely curious.)
>
> It might not necessary mean a better or different API for Phobos. But the lower level APIs could be better.
>
> Classic examples are:
>
> * Use arrays instead of pointers (or pointer length pair). `memcpy` would be:
>
> void[] memcpy(void[] source, void[] destination); // I think it's more natural to pass the source first

Copying code will be same.

> * Better error handling. I think returning error codes or using `errno` is pretty bad error handling strategy. Even though exceptions might not be the right choice (unless something like this is used [1]), something like returning: `Result!(Value, Error)` might be better.

Errno can be covered by druntime like in: https://dlang.org/phobos/core_memory.html#.pureMalloc

>
> * No global symbols, i.e. not having to worry about conflicting names across multiple files

You don't have to worry even now, even if there is a conflict, this can be resolved by linking settings (I propose to switch from DUB to Meson :-))

Really, libc is not (only) C library, but de-facto standard for accessing to OS syscalls. It is possible to drop it but it doesn't make any sense, it just adds extra work to maintain a huge compatibility layer for all supported OSes.

I once thought differently, but recently delved deeper into druntime and looked how it works. In total, I think, there are about ~15 calls to libc, not so many.

On Sunday, 15 November 2020 at 07:21:28 UTC, Denis Feklushkin wrote:
> [...]
>
> Really, libc is not (only) C library, but de-facto standard for accessing to OS syscalls. It is possible to drop it but it doesn't make any sense, it just adds extra work to maintain a huge compatibility layer for all supported OSes.
>
> I once thought differently, but recently delved deeper into druntime and looked how it works. In total, I think, there are about ~15 calls to libc, not so many.

Only for the OSes where C was born on, UNIX and POSIX clones.

There are still several platforms around where this is not the case, because their main systems programming language isn't C, e.g. IBM and Unisys mainframes.

Embedded platforms that use their own toolchains without any kind of POSIX compatibility.

And desktop OSes like Windows, which follows the tradition of C and C++ compilers outside the UNIX world, where each compiler vendor ships their own ISO compliant library, and the OS syscalls are completly unrelated, e.g. ZeroMemory() instead of memset(). Amiga, Atari, OS/2, BeOS, Symbian, Brew, Mac OS pre OS X, Newton, PalmOS, are all examples of this tradition.

On Sunday, 15 November 2020 at 07:51:52 UTC, Paulo Pinto wrote:
> On Sunday, 15 November 2020 at 07:21:28 UTC, Denis Feklushkin wrote:
>> [...]
>>
>> Really, libc is not (only) C library, but de-facto standard for accessing to OS syscalls. It is possible to drop it but it doesn't make any sense, it just adds extra work to maintain a huge compatibility layer for all supported OSes.
>>
>> I once thought differently, but recently delved deeper into druntime and looked how it works. In total, I think, there are about ~15 calls to libc, not so many.
>
> Only for the OSes where C was born on, UNIX and POSIX clones.
>
> There are still several platforms around where this is not the case, because their main systems programming language isn't C, e.g. IBM and Unisys mainframes.
>
> Embedded platforms that use their own toolchains without any kind of POSIX compatibility.
>
> And desktop OSes like Windows, which follows the tradition of C and C++ compilers outside the UNIX world, where each compiler vendor ships their own ISO compliant library, and the OS syscalls are completly unrelated, e.g. ZeroMemory() instead of memset(). Amiga, Atari, OS/2, BeOS, Symbian, Brew, Mac OS pre OS X, Newton, PalmOS, are all examples of this tradition.

Agree. Also threads are not part of the libc, but Posix: if 3-rd party libc provides C standard functions it does not necessarily provides pthread interface.

In this regard, I want to propose related idea to move this dependent from libc and threads and etc parts into a separate druntime package ("backend") so that those who wish can themselves implement  interfaces to these or another more appropriate OS calls.

Something like:
https://github.com/denizzzka/druntime/blob/non_posix/src/core/thread/osthread.d#L217
===>
https://github.com/denizzzka/d_c_arm_test/blob/master/d/freertos_druntime_backend/external/core/thread.d#L396

but without all these "version (DruntimeAbstractRt)" branches.

This will simplify druntime main code (get rid of many versions branches inside of the druntime) and make it possible to easily implement support for various not common operating systems such as HaikuOS or druntime for bare-metal.

On Sunday, 15 November 2020 at 08:12:01 UTC, Denis Feklushkin wrote:
> Agree. Also threads are not part of the libc, but Posix: if 3-rd party libc provides C standard functions it does not necessarily provides pthread interface.

It's catching on https://en.cppreference.com/w/c/thread/thrd_create