View mode: basic / threaded / horizontal-split · Log in · Help
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
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
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
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
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
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
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
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
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.
July 30, 2012
Re: Incomprehensible compiler errors
I notice nobody so far seems to have any idea why I'm getting 
these errors.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home