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?

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.

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

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.

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

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.

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.

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. :)

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.

I notice nobody so far seems to have any idea why I'm getting these errors.