I've been trying to write an OS kernel in D, and I'm having
issues with the runtime. I'm trying to use LDC's -noruntime
option, which is _supposed_ to prevent any runtime calls from
being generated, but the linker keeps complaining about
unresolved references to _d_assert_msg and other runtime
On 06-07-2012 08:53, BLM768 wrote:
I've been trying to write an OS kernel in D, and I'm having issues with
the runtime. I'm trying to use LDC's -noruntime option, which is
_supposed_ to prevent any runtime calls from being generated, but the
linker keeps complaining about unresolved references to
It's not like compiling without a runtime will make the
compiler not emit calls; what else would it do for e.g. the
'new' expression? Anyway, given your situation, just grab the
function prototypes from druntime and stub them out, then fill
them in later.
I knew that stuff like "new" woul
BLM768:
I knew that stuff like "new" wouldn't work without the runtime,
but code that only does a few struct member accesses and a
pointer cast shouldn't require runtime functions; that's all
elementary C stuff.
D isn't C, it was not designed for your very uncommon purpose, it
creates and m
On 2012-07-06 08:53, BLM768 wrote:
I've been trying to write an OS kernel in D, and I'm having issues with
the runtime. I'm trying to use LDC's -noruntime option, which is
_supposed_ to prevent any runtime calls from being generated, but the
linker keeps complaining about unresolved references to
On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:
On 2012-07-06 08:53, BLM768 wrote:
I've been trying to write an OS kernel in D, and I'm having
issues with
the runtime. I'm trying to use LDC's -noruntime option, which
is
_supposed_ to prevent any runtime calls from being generated,
The output of the --help switch suggested that it would
actually keep LDC from generating the calls, but I guess not.
Looks like I've got a rumtime to stub out. At least I'll
understand it better when I'm done.
I meant "runtime." Stupid touch-screen keyboard :).
Check out the Xomb OS as they had to stub things in the runtime
out IIRC, and they use LDC still, I believe. May need to check
out a very old copy to see what they originally did to get a
minimal kernel running.
On Friday, 6 July 2012 at 14:40:19 UTC, BLM768 wrote:
The output of the --hel
On Friday, 6 July 2012 at 15:35:17 UTC, K.Wilson wrote:
Check out the Xomb OS as they had to stub things in the runtime
out IIRC, and they use LDC still, I believe. May need to check
out a very old copy to see what they originally did to get a
minimal kernel running.
I've looked a little at
On Friday, 6 July 2012 at 06:53:11 UTC, BLM768 wrote:
I'm trying to use LDC's -noruntime option […] It seems that
LDC is ignoring the switch and is generating runtime references
anyway.
If this happens, it is a bug – please report it at
https://github.com/ldc-developers/ldc/issues.
David
On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:
It will not prevent the compiler for generating calls to the
runtime.
It should – TypeInfo references will still be generated, though.
So if you see calls to runtime functions you need to stub them
out as Alex suggested or try to f
I swear you guys read my mind sometimes... It's creepy.
I just had this very issue, doing the exact same thing, about an hour ago.
Have you tried with -nodefaultlib -noruntime ? Cause that's what works
for me...
I just got *something* to compile with no runtime or std.
Whether or not it ac
On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:
I swear you guys read my mind sometimes... It's creepy.
I just had this very issue, doing the exact same thing, about
an hour ago.
Have you tried with -nodefaultlib -noruntime ? Cause that's
what works for me...
I just got *something
On Saturday, July 07, 2012 05:45:53 BLM768 wrote:
> On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:
> > I swear you guys read my mind sometimes... It's creepy.
> >
> > I just had this very issue, doing the exact same thing, about
> > an hour ago.
> >
> > Have you tried with -nodefaultlib
Wow, I haven't had that much trouble. But I've tried to keep everything
at my level. It's about half xomb. =P
I salute you for your bravery.
I had planned to stay far, far away from as much of that as I could.
On Fri, 06 Jul 2012 22:45:53 -0500, BLM768 wrote:
On Friday, 6 July 2012 at 21
On 07-07-2012 06:26, Jonathan M Davis wrote:
On Saturday, July 07, 2012 05:45:53 BLM768 wrote:
On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:
I swear you guys read my mind sometimes... It's creepy.
I just had this very issue, doing the exact same thing, about
an hour ago.
Have you tr
On Saturday, 7 July 2012 at 04:27:07 UTC, Jonathan M Davis wrote:
On Saturday, July 07, 2012 05:45:53 BLM768 wrote:
On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:
> I swear you guys read my mind sometimes... It's creepy.
>
> I just had this very issue, doing the exact same thing, about
On Saturday, July 07, 2012 07:27:52 Alex Rønne Petersen wrote:
> Is overriding a @safe function with @trusted allowed/meant to be
> allowed? I hope so, otherwise this is going to be a severe limitation.
Well, an overriding function in a derived class cannot be any looser than the
one it's overrid
On 2012-07-06 21:42, David Nadlinger wrote:
On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:
It will not prevent the compiler for generating calls to the runtime.
It should – TypeInfo references will still be generated, though.
So what happens with code like this:
auto o = new
19 matches
Mail list logo
