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
> 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 actually does anything remains to be seen.
No luck; it still references the runtime.
I've been stubbing out the runtime; it seems to be about done
except for references to some functions I can't find. The
symbols
are __moddi3 and __divdi3; I assume they're C math library
functions, as they're generated from code that uses div/mod
operations. It also seems to be unable to properly find
Object.toString() after I changed it to be nothrow, which I
needed to do because I'm stubbing out the exception handling
routines; it seems to have changed the mangling. It's a bit of
a
mess in there; I'm glad I don't always have to hack up the
runtime :).
Yes. nothrow is part of the name mangling, because it's part of
the signature.
In the long run, toString will be @safe const pure nothrow, but
it's not there
quite yet (const correctness and Object is still being sorted
out would be one
reason; a number of key string-related functions need to become
pure for
another). But if the compiler is expecting a specific
signature, then that's
the signature that you're going to have to give it, or the
linker's not going
to find the function when it goes to look for it.
- Jonathan M Davis
The problem is that if I leave the try/catch block, it's
referring to stubbed-out functions, and if I get rid of it, LDC
complains that toString() isn't nothrow. I guess I'd just better
leave it in and hope that toString() never gets called. I could
throw in an assert(false), which I'll have wired up to just cause
a kernel panic.
