Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 30, 2012 Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
I'm trying to write an actual program in D, but no matter what I do I get stupid errors that mean nothing to me. (Reminds me of C++) Error 42: Symbol Undefined _D8infinity8standard7runtime4IApp4IApp11__InterfaceZ Huh? This usually happens if I omit the module statement at the top of EVERY DAMN FILE (why???) but in this case I haven't omitted it, yet I'm still getting the error. Also, I get the following error: Error 42: Symbol Undefined _D3dfl8internal6winapi12__ModuleInfoZ The code producing this second error is: int Run() { import core.sys.windows.windows; import dfl.internal.winapi; MSG msg; while (GetMessageA(&msg, null, 0, 0)) { TranslateMessage(&msg); DispatchMessageA(&msg); if (msg.hwnd && !IsWindow(msg.hwnd)) break; } return 0; } What the HELL is this "ModuleInfo", why is it necessary, why is it always missing when a "module" statement is not present, and why is it missing NOW? |
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stuart Attachments:
| On Mon, Jul 30, 2012 at 8:31 PM, Stuart <stugol@gmx.com> wrote: > I'm trying to write an actual program in D, but no matter what I do I get stupid errors that mean nothing to me. (Reminds me of C++) > > Error 42: Symbol Undefined > _**D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ > > Huh? This usually happens if I omit the module statement at the top of EVERY DAMN FILE (why???) but in this case I haven't omitted it, yet I'm still getting the error. > > Also, I get the following error: > > Error 42: Symbol Undefined > _D3dfl8internal6winapi12__**ModuleInfoZ > > The code producing this second error is: > > int Run() { > import core.sys.windows.windows; > import dfl.internal.winapi; > MSG msg; > while (GetMessageA(&msg, null, 0, 0)) { > TranslateMessage(&msg); > DispatchMessageA(&msg); > if (msg.hwnd && !IsWindow(msg.hwnd)) break; > } > return 0; > } > > What the HELL is this "ModuleInfo", why is it necessary, why is it always missing when a "module" statement is not present, and why is it missing NOW? > For one, it would be mighty polite of the compiler to demangle the "_** D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which happens to be "infinity.standard.runtime.App.App.__Interface". The ModuleInfo is a half-working runtime reflection structure, which the compiler successfully fails to build when you omit the optional module declaration. -- Bye, Gor Gyolchanyan. |
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gor Gyolchanyan | On 30-07-2012 18:38, Gor Gyolchanyan wrote: > On Mon, Jul 30, 2012 at 8:31 PM, Stuart <stugol@gmx.com > <mailto:stugol@gmx.com>> wrote: > > I'm trying to write an actual program in D, but no matter what I do > I get stupid errors that mean nothing to me. (Reminds me of C++) > > Error 42: Symbol Undefined > ___D8infinity8standard7runtime4IA__pp4IApp11__InterfaceZ > > Huh? This usually happens if I omit the module statement at the top > of EVERY DAMN FILE (why???) but in this case I haven't omitted it, > yet I'm still getting the error. > > Also, I get the following error: > > Error 42: Symbol Undefined > _D3dfl8internal6winapi12____ModuleInfoZ > > The code producing this second error is: > > int Run() { > import core.sys.windows.windows; > import dfl.internal..winapi; > MSG msg; > while (GetMessageA(&msg, null, 0, 0)) { > TranslateMessage(&msg); > DispatchMessageA(&msg); > if (msg.hwnd && !IsWindow(msg.hwnd)) break; > } > return 0; > } > > What the HELL is this "ModuleInfo", why is it necessary, why is it > always missing when a "module" statement is not present, and why is > it missing NOW? > > > For one, it would be mighty polite of the compiler linker > to demangle the > "___D8infinity8standard7runtime4IA__pp4IApp11__InterfaceZ", which > happens to be "infinity.standard.runtime.App.App.__Interface". > > The ModuleInfo is a half-working runtime reflection structure, which the > compiler successfully fails to build when you omit the optional module > declaration. > > -- > Bye, > Gor Gyolchanyan. -- Alex Rønne Petersen alex@lycus.org http://lycus.org |
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gor Gyolchanyan | On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
> For one, it would be mighty polite of the compiler to demangle the "_**
> D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which happens to be
> "infinity.standard.runtime.App.App.__Interface".
The linker spits out those errors. It would be unreasonable to
expect linkers to understand D's name mangling scheme.
|
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | Peter Alexander:
> The linker spits out those errors. It would be unreasonable to
> expect linkers to understand D's name mangling scheme.
Then the output of the linker should be hidden, and the programmer should see only some filtered and cleaned error text. It's another little step to pull out of '70 the D compilations :-)
Bye,
bearophile
|
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Monday, 30 July 2012 at 17:16:04 UTC, bearophile wrote:
> Then the output of the linker should be hidden, and the programmer should see only some filtered and cleaned error text.
yea the compiler could run something like
linker | demangle
rather than just linker and make it a little prettier.
|
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander Attachments:
| On Mon, Jul 30, 2012 at 9:12 PM, Peter Alexander < peter.alexander.au@gmail.com> wrote: > On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote: > >> For one, it would be mighty polite of the compiler to demangle the "_** >> D8infinity8standard7runtime4IA****pp4IApp11__InterfaceZ", which happens >> to be >> "infinity.standard.runtime.**App.App.__Interface". >> > > The linker spits out those errors. It would be unreasonable to expect linkers to understand D's name mangling scheme. > > The compiler calls the linker (in cases where it's linking of course). It wouldn't be too difficult to intercept the linker's output. -- Bye, Gor Gyolchanyan. |
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On 7/30/12, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
>> For one, it would be mighty polite of the compiler to demangle the "_** D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which happens to be "infinity.standard.runtime.App.App.__Interface".
>
> The linker spits out those errors. It would be unreasonable to expect linkers to understand D's name mangling scheme.
unilink understands it!
Optlink, well.. we windevs all know optlink too well. :)
|
July 30, 2012 Re: Incomprehensible compiler errors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Monday, 30 July 2012 at 17:12:11 UTC, Peter Alexander wrote:
> On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
>> For one, it would be mighty polite of the compiler to demangle the "_**
>> D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which happens to be
>> "infinity.standard.runtime.App.App.__Interface".
>
> The linker spits out those errors. It would be unreasonable to
> expect linkers to understand D's name mangling scheme.
This problem was already solved by Turbo Pascal in the 80's, by making use of smart linkers integrated with the compiler.
Many other languages follow similar module systems.
|
Copyright © 1999-2021 by the D Language Foundation