www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - LINK : fatal error LNK1104: cannot open file '_CMDLINE' ---

reply Jason Jeffory <JasonJeffory doodle.com> writes:
Any ideas? Happens when I do a very simple dub project and try to 
compile using the MS linker(x86 but set in sc.ini or 64). I'm 
linking in glfw(using correct arch of course)


{
	"name": "Test",
	"description": "A minimal D application.",
	"copyright": "Copyright © 2016, Jason",
	"authors": ["Jason"],
	"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
	"dflags-dmd": [""],
	"versions-x86_64": ["UseAmd64Impl"],
	"dependencies": {
	}
}
Jan 11 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory wrote:

 Any ideas? Happens when I do a very simple dub project and try 
 to compile using the MS linker(x86 but set in sc.ini or 64). 
 I'm linking in glfw(using correct arch of course)


 {
 	"name": "Test",
 	"description": "A minimal D application.",
 	"copyright": "Copyright © 2016, Jason",
 	"authors": ["Jason"],
 	"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
 	"dflags-dmd": [""],
 	"versions-x86_64": ["UseAmd64Impl"],
 	"dependencies": {
 	}
 }


seems "versions-x86_64": ["UseAmd64Impl"],

doesn't actually make it 64

                                        ******
Performing "debug" build using dmd for x86.
midimonitor ~master: building configuration "application"...
Linking...
Microsoft (R) Incremental Linker Version 14.00.23506.0
Copyright (C) Microsoft Corporation.  All rights reserved.

LINK : fatal error LNK1104: cannot open file '_CMDLINE'
--- errorlevel 1104
dmd failed with exit code 1104.

Sheesh, why is it so hard to do simple stuff?
Jan 11 2016
next sibling parent reply Tobi G. <gruen_tobias web.de> writes:
On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:

 Sheesh, why is it so hard to do simple stuff?
 


1) Have you tryed passing --arch=x86_64 to dub?

2) > "versions-x86_64": ["XYZ"]

This is like a architecture dependent condition for version 
definition.

So if your project will be compiled for the architecture x86_64 
the version XYZ will be defined in your code.


togrue
Jan 11 2016
parent Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 23:26:51 UTC, Tobi G. wrote:

 On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:

 Sheesh, why is it so hard to do simple stuff?
 


 1) Have you tryed passing --arch=x86_64 to dub?

 2) > "versions-x86_64": ["XYZ"]

 This is like a architecture dependent condition for version 
 definition.

 So if your project will be compiled for the architecture x86_64 
 the version XYZ will be defined in your code.


 togrue



Yeah, I realized that after the fact. I saw that in some post and 
tried it. couldn't find anything in the dub docs that explain how 
to compile for x64... I want to specify in the json. I don't want 
to have to remember a command to compile for the same arch every 
time. In fact, I'd like to have two profiles for dub...

one for 32-bit and one for 64-bit.
Jan 11 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:

 On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory wrote:

 Any ideas? Happens when I do a very simple dub project and try 
 to compile using the MS linker(x86 but set in sc.ini or 64). 
 I'm linking in glfw(using correct arch of course)


 {
 	"name": "Test",
 	"description": "A minimal D application.",
 	"copyright": "Copyright © 2016, Jason",
 	"authors": ["Jason"],
 	"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
 	"dflags-dmd": [""],
 	"versions-x86_64": ["UseAmd64Impl"],
 	"dependencies": {
 	}
 }


 seems "versions-x86_64": ["UseAmd64Impl"],

 doesn't actually make it 64

                                        ******
 Performing "debug" build using dmd for x86.
 midimonitor ~master: building configuration "application"...
 Linking...
 Microsoft (R) Incremental Linker Version 14.00.23506.0
 Copyright (C) Microsoft Corporation.  All rights reserved.

 LINK : fatal error LNK1104: cannot open file '_CMDLINE'
 --- errorlevel 1104
 dmd failed with exit code 1104.

 Sheesh, why is it so hard to do simple stuff?


There's nothing hard about it. It's just a matter of learning 
what's what.

First, don't set 32/64-bit compilation in sc.ini. In fact, you 
should generally never touch sc.ini (more on that below). If you 
are calling DMD directly, just pass -m64 on the command line. If 
you are using DUB, pass -ax86_64 on the command line.

Second, you don't need to set your own version flag for 64-bit. 
Both x86_64 and Win64 are already predefined [1]. The latter is 
only defined on when compiling for 64-bit Windows (Win32 is only 
defined when compiling for 32-bit Windows, unlike in the C world 
where the #defined _WIN32 means the Win32 API is available). 
Should you need to, you can also distinguish between the two 
Windows runtimes via the CRuntime_DigitalMars and 
CRuntime_Microsoft versions.

The only time you should need to configure sc.ini is when you are 
setting up DMD manually for 64-bit compilation. If you are using 
the installer and already have the Microsoft toolchain installed, 
the DMD installer will find it and configure sc.ini 
appropriately. And while it may be tempting to add a custom 
library path to sc.ini, it's probably easier not to if you only 
are using one path. Then you don't have to worry about updating 
it every time you install a new copy of DMD and you can use 
multple DMD installations (useful for testing and maintaining 
backward compatibility) without keeping all of the sc.ini files 
up to date. If you don't want to configure the lib path per 
project, IIRC you should be able to set the library path as an 
environment variable and the linker will pick it up. I've never 
tried that, as I tend to store any static libraries I need in the 
source tree of each project and configure the path in my dub.sdl, 
but I believe it should work.

[1] http://dlang.org/spec/version.html
Jan 11 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 12 January 2016 at 01:26:06 UTC, Mike Parker wrote:

 On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:

 On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory 
 wrote:

 Any ideas? Happens when I do a very simple dub project and 
 try to compile using the MS linker(x86 but set in sc.ini or 
 64). I'm linking in glfw(using correct arch of course)


 {
 	"name": "Test",
 	"description": "A minimal D application.",
 	"copyright": "Copyright © 2016, Jason",
 	"authors": ["Jason"],
 	"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
 	"dflags-dmd": [""],
 	"versions-x86_64": ["UseAmd64Impl"],
 	"dependencies": {
 	}
 }


 seems "versions-x86_64": ["UseAmd64Impl"],

 doesn't actually make it 64

                                        ******
 Performing "debug" build using dmd for x86.
 midimonitor ~master: building configuration "application"...
 Linking...
 Microsoft (R) Incremental Linker Version 14.00.23506.0
 Copyright (C) Microsoft Corporation.  All rights reserved.

 LINK : fatal error LNK1104: cannot open file '_CMDLINE'
 --- errorlevel 1104
 dmd failed with exit code 1104.

 Sheesh, why is it so hard to do simple stuff?


 There's nothing hard about it. It's just a matter of learning 
 what's what.


Um, if there was proper documentation, this wouldn't be a problem.


 First, don't set 32/64-bit compilation in sc.ini. In fact, you 
 should generally never touch sc.ini (more on that below). If 
 you are calling DMD directly, just pass -m64 on the command 
 line. If you are using DUB, pass -ax86_64 on the command line.


I don't set that in sc.ini, but you have to set the correct 
paths. It works fine with VS/VD.

I also don't want to pass a command line to dub. Too much work. 
What if I forget? What about the correct libs?  What if I forget 
to type dub -ax86_64 and it tries to compile in the 64-bit lib in 
the lib's path in sc.ini?(yes, it needs to be edited for global 
library locations).



 Second, you don't need to set your own version flag for 64-bit. 
 Both x86_64 and Win64 are already predefined [1]. The latter is 
 only defined on when compiling for 64-bit Windows (Win32 is 
 only defined when compiling for 32-bit Windows, unlike in the C 
 world where the #defined _WIN32 means the Win32 API is 
 available). Should you need to, you can also distinguish 
 between the two Windows runtimes via the CRuntime_DigitalMars 
 and CRuntime_Microsoft versions.


This was a mistake, because I got the wrong info from some forum 
post that was wrong.


So, how do I set the json to compile for x64?
Jan 11 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 01:44:17 UTC, Jason Jeffory wrote:


 So, how do I set the json to compile for x64?


You don't. You pass -ax86_64 (or --arch=x86_64) on the command 
line. If you find that inconvenient, just make a batch file to do 
it for you.
Jan 11 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 03:47:35 UTC, Mike Parker wrote:

 On Tuesday, 12 January 2016 at 01:44:17 UTC, Jason Jeffory 
 wrote:


 So, how do I set the json to compile for x64?


 You don't. You pass -ax86_64 (or --arch=x86_64) on the command 
 line. If you find that inconvenient, just make a batch file to 
 do it for you.


Actually, you could add -m64 in a dflags field (see [1]), but 
then you're in a situation where DUB thinks you're compiling in 
32-bit, so configuration fields that are architecture-dependent 
will be off.
Jan 11 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 03:52:33 UTC, Mike Parker wrote:

 Actually, you could add -m64 in a dflags field (see [1]), but 
 then you're in a situation where DUB thinks you're compiling in 
 32-bit, so configuration fields that are architecture-dependent 
 will be off.


[1] http://code.dlang.org/package-format?lang=json
Jan 11 2016
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 12/01/16 4:53 PM, Mike Parker wrote:

 On Tuesday, 12 January 2016 at 03:52:33 UTC, Mike Parker wrote:

 Actually, you could add -m64 in a dflags field (see [1]), but then
 you're in a situation where DUB thinks you're compiling in 32-bit, so
 configuration fields that are architecture-dependent will be off.


 [1] http://code.dlang.org/package-format?lang=json


If you really must default dub to it, just build a custom dub build.
Its not all that hard.
Jan 11 2016