LDC -noruntime

[BLM768]

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.