Thread overview
VisualD can't build x64, Internal error: backend\mscoffobj.c 2016
6 days ago
Rainer Schuetze
March 17
Building with dub works fine, I can even build with dub and debug the exe in VS2013/15. I generated the VisualD project from dub, tried debug and release, tried the recently released VisualD the version before both the same error. I tried to enable "Use MS-COFF object file format for Win32" on each separate project in the solution and confirmed that the linker for x64 is set to "$(VCINSTALLDIR)bin\link.exe" in the global project and solution settings.

What am I missing?
March 17

On 17.03.2017 12:28, ParticlePeter wrote:
> Building with dub works fine, I can even build with dub and debug the
> exe in VS2013/15. I generated the VisualD project from dub, tried debug
> and release, tried the recently released VisualD the version before both
> the same error. I tried to enable "Use MS-COFF object file format for
> Win32" on each separate project in the solution and confirmed that the
> linker for x64 is set to "$(VCINSTALLDIR)bin\link.exe" in the global
> project and solution settings.
>
> What am I missing?

backend\mscoffobj.c is a source file of dmd, not Visual D. The given line contains an assert in dmd 2.073, but is in a very generic function, so it's hard to tell what has gone wrong.

You might want to extract the dmd command line from the build log and reduce it to see what command line option is actually causing the assert.
March 20
On Friday, 17 March 2017 at 22:01:55 UTC, Rainer Schuetze wrote:

> backend\mscoffobj.c is a source file of dmd, not Visual D. The given line contains an assert in dmd 2.073, but is in a very generic function, so it's hard to tell what has gone wrong.
>
> You might want to extract the dmd command line from the build log and reduce it to see what command line option is actually causing the assert.

Thanks for your reply, I tried it. The problem in my case is the -c flag (compile only, do not link ). Without that flag everything works fine.

How do I get rid of that flag through the visuald project settings? Can't figure it out.
March 20

On 20.03.2017 11:32, ParticlePeter wrote:
> On Friday, 17 March 2017 at 22:01:55 UTC, Rainer Schuetze wrote:
>
>> backend\mscoffobj.c is a source file of dmd, not Visual D. The given
>> line contains an assert in dmd 2.073, but is in a very generic
>> function, so it's hard to tell what has gone wrong.
>>
>> You might want to extract the dmd command line from the build log and
>> reduce it to see what command line option is actually causing the assert.
>
> Thanks for your reply, I tried it. The problem in my case is the -c flag
> (compile only, do not link ). Without that flag everything works fine.
>
> How do I get rid of that flag through the visuald project settings?
> Can't figure it out.

-c tells dmd to just compile, not link. Pretty strange that this might make a difference during object file generation (that's what mscoffobj.c does).

You might reduce the error a bit by switching to "single file compilation". Or try dustmite to reduce the error (see http://rainers.github.io/visuald/visuald/DustMite.html).
March 21
On Monday, 20 March 2017 at 19:00:04 UTC, Rainer Schuetze wrote:
>
> -c tells dmd to just compile, not link. Pretty strange that this might make a difference during object file generation (that's what mscoffobj.c does).
>
> You might reduce the error a bit by switching to "single file compilation".

I tried all settings under 'Configuration Properties -> General -> Compilation'

Combined compile and link: Exactly what I was asking for, removes the -c flag and lets dmd invoke the proper linker. Resulting executable works flawlessly.

Single file compilation: (as you suggested) does not compile as a specific module could not be found. Path to that module is NOT in the search paths listed, however, the module IS in the Solution Explorer tree. Shouldn't that be enough for visuald to include it in the compilation process? Moreover shouldn't 'Combined compile and link' have the same issue? Anyway, after adding the path manually the build and link went through and the executable works.

Separate compile and link / Compile only: both mscoffobj.c error.

> Or try dustmite to reduce the error (see http://rainers.github.io/visuald/visuald/DustMite.html).

Don't get dustmite working, immediately after invoking it complains about the first module (first in single file compilation and first listed in solution explorer):
The process cannot access the file because it is being used by another process.

I made sure that no other processes are running, in particular ST3 with DCD.

Anyway my issue is sufficiently solved, I can work with that. But if you still want to look into it I am happy to assist.
6 days ago
On 21.03.2017 10:50, ParticlePeter wrote:
> Single file compilation: (as you suggested) does not compile as a
> specific module could not be found. Path to that module is NOT in the
> search paths listed, however, the module IS in the Solution Explorer
> tree. Shouldn't that be enough for visuald to include it in the
> compilation process? Moreover shouldn't 'Combined compile and link' have
> the same issue? Anyway, after adding the path manually the build and
> link went through and the executable works.

With combined compilation, imports are resolved by modules given on the command line first. With single file compilation imports must go through the file system and need appropriate import search paths.

>
>> Or try dustmite to reduce the error (see
>> http://rainers.github.io/visuald/visuald/DustMite.html).
>
> Don't get dustmite working, immediately after invoking it complains
> about the first module (first in single file compilation and first
> listed in solution explorer):
> The process cannot access the file because it is being used by another
> process.

It's not clear if it is the problem here, but dustmite integration doesn't work with single file compilation (also mentioned in the documentation). Maybe there is also a problem if the source files are located somewhere completely different (as the issue with single file compilation suggests).

>
> I made sure that no other processes are running, in particular ST3 with
> DCD.
>
> Anyway my issue is sufficiently solved, I can work with that. But if you
> still want to look into it I am happy to assist.

If your code is publicly available somewhere, I can have a look. Having mscoffobj.c error out depending on -c is pretty strange.