On 6/20/17 7:23 AM, Jacob Carlborg wrote:
> On 2017-06-20 01:29, Steven Schveighoffer wrote:
> 
>> I may have misspoke. I mean they didn't depend on the library itself. I think they do depend on the C wrappers.
>>
>> So for instance, they didn't use FILE *, but instead used read/write/recv/send.
> 
> They did use the Posix and Windows API functions. I can see some imports for libc and Posix functions spread out here and there [1], but I'm not too familiar with are system calls and which are not. It's certainly no way near how much is used in Phobos today.

I remember they specifically did not want to depend on anything in the C library.

In windows, they definitely did not depend on C at all, and did not link with msvcrt or any other C runtime. The calls were all to the ntdll.dll.  Really this is the way it *should* be in Posix as well, but they just stuff everything into libc.

As it stands, Phobos uses C runtime features extensively, and it would be hard to get rid of the calls.

-Steve

On 6/19/17 7:47 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> On Mon, Jun 19, 2017 at 07:29:46PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
>> On 6/19/17 5:45 PM, Moritz Maxeiner wrote:
>>> On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
>>>> IIRC, Tango did not depend on libc at all. It only used system
>>>> calls. So it certainly is possible.
>>>
>>> How did they invoke those system calls? They are usually access via
>>> libc on POSIX systems, so you don't have to implement accessing e.g.
>>> vdso on Linux yourself.
>>
>> I may have misspoke. I mean they didn't depend on the library itself.
>> I think they do depend on the C wrappers.
>>
>> So for instance, they didn't use FILE *, but instead used
>> read/write/recv/send.
>>
>> I don't know what's involved in creating those wrappers, but I can't
>> imagine it's difficult to do with D (it's probably actually easier
>> than in C/assembly).
> [...]
> 
> The downside of that is that then we can no longer leverage the work
> done by libc authors to interface with that particular OS / platform.
> Meaning we have to maintain this low-level code ourselves, which
> includes potentially keeping up with OS-level changes that would
> otherwise be transparent had we used the libc wrappers. Sadly, we're not
> yet in the day when libd authors would do this for us with every new OS
> that comes out. :-D

Of course! It would not be a small task. But D has some rather nice generational features.

One of my favorite Dconf talks of all time is still Mike Franklin's talk from 2014 (http://dconf.org/2014/talks/franklin.html), which has a part in it where he wrote D code to parse the pdf spec of a microcontroller and AUTOMATICALLY GENERATE the correct register mappings. Think about that -- 0 effort to maintain hundreds or thousands of registers, with no mistakes! I'm frankly disappointed that D did not service Mike enough to continue using D, as he seemed a very bright and motivated user.

I think we could do something similar in D for the OS calls.

What is the point, you might ask? The only true point is to have control over every part of the userspace call chains. You don't need a FILE * for stdout? Fine, just use this small wrapper. Who knows what magic can be performed if the compiler has full access to the system calls for inlining and optimization.

I'm not saying I want to do this or that it's really important. But there are possible reasons to do it, even if it's just for the coolness factor :)

-Steve

On Tuesday, 20 June 2017 at 12:09:06 UTC, Jacob Carlborg wrote:
>
> LLD, the LLVM linker [1]. As far as I understand it, it also support cross-platform linking. Using LDC, musl and LLD you have a fully working cross-compiler tool chain. You might need some extra libraries as well, depending on what you need.

Hm, so then we could provide a self-contained installer for all major platforms that bundles all you need to get started with D. Neat.

On Tuesday, 20 June 2017 at 18:51:17 UTC, Moritz Maxeiner wrote:
> On Tuesday, 20 June 2017 at 12:09:06 UTC, Jacob Carlborg wrote:
>>
>> LLD, the LLVM linker [1]. As far as I understand it, it also support cross-platform linking. Using LDC, musl and LLD you have a fully working cross-compiler tool chain. You might need some extra libraries as well, depending on what you need.
>
> Hm, so then we could provide a self-contained installer for all major platforms that bundles all you need to get started with D. Neat.

Yes, that's part of the idea behind the ongoing work to integrate LLD into LDC: https://github.com/ldc-developers/ldc/pull/2142

For Windows, we use the MS C runtime, though, and the legal situation around redistribution seems a bit unclear.

 — David

On 2017-06-20 14:10, Steven Schveighoffer wrote:

> I remember they specifically did not want to depend on anything in the C library.

I can only tell you what I read from the source code :) . I didn't know enough about these things back in the D1 and Tango days.

-- 
/Jacob Carlborg

On 2017-06-20 21:59, David Nadlinger wrote:

> For Windows, we use the MS C runtime, though, and the legal situation around redistribution seems a bit unclear.

Musl (or similar) should be available as an alternative. That will make it easier to cross-compile as well. But I guess MS C runtime is required for linking with other existing C libraries.

-- 
/Jacob Carlborg

On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote:
> Musl (or similar) should be available as an alternative. That will make it easier to cross-compile as well.

This is not relevant for cross-compilation, as long as you have the libraries available. You can actually link a D Windows x64/MSVCRT executable from Linux today if you copy over the necessary libraries. The question is just how we can make this as easy as possible for users.

 — David

On 2017-06-21 17:51, David Nadlinger wrote:

> This is not relevant for cross-compilation, as long as you have the
> libraries available. You can actually link a D Windows x64/MSVCRT
> executable from Linux today if you copy over the necessary libraries.
> The question is just how we can make this as easy as possible for users.

Perhaps not when targeting Windows but when targeting Linux. Can you target a specific version of libc or do you need to use static linking?

-- 
/Jacob Carlborg