www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - VisualD can't build x64, Internal error: backend\mscoffobj.c 2016

reply ParticlePeter <ParticlePeter gmx.de> writes:
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?
Mar 17 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Mar 17 2017
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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.
Mar 20 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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).
Mar 20 2017
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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.
Mar 21 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Mar 22 2017
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Wednesday, 22 March 2017 at 21:13:14 UTC, Rainer Schuetze 
wrote:


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


Yes, thanks, buuuuut ... you'll need a Vulkan compatible gpu and 
the lunarG Vulkan SDK, don't know if I can bother you with this. 
Additionally, there is no visuald project file, generate it with 
dub:
dub generate visuald --build=debug --arch=x86_64 vdrive:triangle

Here is the repo:
https://github.com/ParticlePeter/V-Drive
Mar 29 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 29.03.2017 20:52, ParticlePeter wrote:

 On Wednesday, 22 March 2017 at 21:13:14 UTC, Rainer Schuetze wrote:


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


 Yes, thanks, buuuuut ... you'll need a Vulkan compatible gpu and the
 lunarG Vulkan SDK, don't know if I can bother you with this.
 Additionally, there is no visuald project file, generate it with dub:
 dub generate visuald --build=debug --arch=x86_64 vdrive:triangle

 Here is the repo:
 https://github.com/ParticlePeter/V-Drive


Well, I don't need that hardware to compile your code ;-) Dustmite 
integration seems to fail due to absolute paths generated into the 
project file by dub. I could run it manually, though, and reduce it to a 
couple of files with very few lines just to notice that it doesn't occur 
with dmd 2.074-b1, so it's likely fixed already.
Apr 01 2017
parent ParticlePeter <ParticlePeter gmx.de> writes:
On Saturday, 1 April 2017 at 14:50:59 UTC, Rainer Schuetze wrote:


 Well, I don't need that hardware to compile your code ;-)


Yes of course you're right, silly me :-)


 Dustmite integration seems to fail due to absolute paths 
 generated into the project file by dub. I could run it 
 manually, though, and reduce it to a couple of files with very 
 few lines just to notice that it doesn't occur with dmd 
 2.074-b1, so it's likely fixed already.


O.k., thanks for your time! Will try that dmd version.
Apr 04 2017