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
