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
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
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
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
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
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
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
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
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
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