On Sunday, 12 June 2016 at 03:22:06 UTC, Mike Parker wrote:
On Sunday, 12 June 2016 at 02:09:24 UTC, Joerg Joergonson wrote:
Ok, So I started an empty project and I found all the libs
that are required from all of VS, SDK, LDC, DMD, etc and put
them in 4 folders:
Libs\COFF\x86
Libs\COFF\x64
Libs\OMF\x86
Libs\OMF\x64
There's no need for OMF\x64. OPTLINK is 32-bit only. That's why
DMD uses the MS tools for 64-bit. And you never need OMF for
LDC.
Yeah, I know. That's why it's empty. I made it anyways though to
be consistent and not knowing if there was possibly any use. I
wanted to make sure to cover all cases.
fixed up sc.ini and VD to use them and worked on stuff until I
had no lib errors with the test project. I could compile with
all versions now(DMD x86/64, LDC x86/64)
You said in your previous post that DMD was working fine for
you. I would recommend against editing sc.ini except in the
case where you do manual installs of DMD and need to configure
it to work with Visual Studio. It's a pain to have to do it
every time you update. Much better to use the installer and let
it configure the VS paths for you.
Well, it's never really worked before. I've always had to
manually edit it and add the VS sdk paths to get DMD working. The
problem is, when you have many SDK's and kits, nothing plays nice
together.
What I have now is at least something that is consistent and I
can simply archive it all and it should work in all future cases.
Uninstalling a kit and reinstalling one isn't going to fubar dmd.
I'll keep it this way because it works and the only issue is
keeping it up to date. At least I don't have to go looking in
some crazy long path for VS libs like C:\program files
(x86)\Visual Studio\VC\Lib\um\arm\x86\amd\aldlf\crapola\doesn't
contain everything\1.0534.43030204534333314159265.
So, ldc is essentially working... gdc probably is the same if
I can figure out how to get the proper binaries(not that
arm-unknown-linux crap) that are not so far out of date. At
this point I still need to get ldc to work though.
I would recommend against GDC for now. Until someone steps up
and starts packaging regular MinGW-based releases, it's
probably not worth it.
Ok. I'll stick with LDC if it works since at least there is a
something that can be used for properly releasing software.
I probably just need to figure out how to properly include the
library files mentioned in my other post.
I did try to include the path to the files in VD's LDC
settings section but it did nothing.
Did you also include the libraries in the project settings? You
can:
A) Add the path to 'Library Search Path' and add the library
names to 'Library Files' or,
B) Add the full path and filename for each library to 'Library
Files'.
I strongly recommend against doing this for system libraries
like OpenGL. If LDC is configured to know where your VS
installation is (the only version of LDC I've ever used was an
old MinGW-based one, so I don't know how the VS version finds
the MS libraries), then you should only need to include the
file name and it will use the one from the MS SDK.
Well, I don't know. I monitored LDC2 and it is actually searching
for the modules with out the slash:
B:\Software\App\Test\libmBase.d
When it should be
B:\Software\App\Test\lib\mBase.d
I created a test project that mimics the main project and it
works and does not have that issue... So possibly my project is
"corrupt". I will try and mess with it later or move the project
over into a new one incrementally until the issue happens.
---
Ok, tried a simple copy and paste type of thing and same issue.
This seems to be a bug in ldc or visual d.
--
Ok, this is a bug in ldc.
1. I had an older distro(I think) of ldc. The ldc2.exe is 18MB
while the "new" one is 36MB. I copied the old ldc bin dir to the
new one and didn't change anything and everything compiled EXCEPT
2. I got an error that I don't get with dmd:
Error: incompatible types for ((ScreenPainter) !is (null)):
cannot use '!is' with types
and I have defined ScreenPainter in my code. It is also in arsd's
simpledisplay. I do not import simpledisplay directly:
The code is
import arsd.gamehelpers;
auto window = create2dWindow(cast(int)width, cast(int)height,
cast(int)ViewportWidth, cast(int)ViewportHeight, title);
// Let the gui handle painting the screen
window.redrawOpenGlScene = {
if (ScreenPainter !is null || !ScreenPainter()) <--- error
...
};
I have defined ScreenPainter elsewhere in the module.
I can fix this by avoiding the import... but the point is that
it's different than dmd.
So ldc parses things differently than dmd... I imagine this is a
bug!
Fixing it though does produce an executable!
Although, If I set the subsystem to windows I then get the error
error LNK2019: unresolved external symbol WinMain referenced in
function "int __cdecl __scrt_common_main_seh(void)"
(?__scrt_common_main_seh@@YAHXZ)
for x64 build, for x86 I get all kinds of undefined externals
simpledisplay.obj : error LNK2001: unresolved external symbol
__D9Exception7__ClassZ
png.obj : error LNK2001: unresolved external symbol __d_newclass
simpledisplay.obj : error LNK2001: unresolved external symbol
__d_newclass
winmain.obj : error LNK2001: unresolved external symbol
__d_newclass
color.obj : error LNK2001: unresolved external symbol __d_newclass
gamehelpers.obj : error LNK2001: unresolved external symbol
__d_newclass
referenced in function
__D3std6format18__T10FormatSpecTaZ10FormatSpec6fillUpMFNaNfZv
(pure @safe void std.format.FormatSpec!(char).FormatSpec.fillUp())
color.obj : error LNK2001: unresolved external symbol
__D9Exception6__vtblZ
png.obj : error LNK2001: unresolved external symbol
__D9Exception6__vtblZ
simpledisplay.obj : error LNK2001: unresolved external symbol
__D9Exception6__vtblZ
....
Which looks like it's not linking to runtime and/or phobos?
Here are the versions
The one that isn't working:
LDC - the LLVM D compiler (30b1ed):
based on DMD v2.071.1 and LLVM 3.9.0git-d06ea8a
built with LDC - the LLVM D compiler (1.0.0)
Default target: x86_64-pc-windows-msvc
Host CPU: skylake
http://dlang.org - http://wiki.dlang.org/LDC
The one that is:
B:\DLang\ldc2\bin>ldc2 -version
LDC - the LLVM D compiler (1.0.0):
based on DMD v2.070.2 and LLVM 3.9.0git
built with LDC - the LLVM D compiler (1.0.0)
Default target: i686-pc-windows-msvc
Host CPU: skylake
http://dlang.org - http://wiki.dlang.org/LDC
I seriously don't know how anyone gets anything done with all
these problems ;/ The D community can't expect to get people
interested in things don't work. If it wasn't because the D
language was so awesome I wouldn't stick around! It's as if no
one does any real testing on this stuff before it's released ;/
Anyways, because the above is a bit convoluted(trying to figure
out the problems as I'm posting):
1. LDC has a bug in it. Simple as that. Replacing ldc2's bin dir
with older ldc2 version essentially solved the problem(that being
it not parsing paths correctly).
2. LDC has a discontinuity with dmd. Maybe fixed in the latest
version... but I can't tell.
3. LDC x64 cannot find "winmain" or whatever while DMD does. This
is if the subsystem is set to windows. If set to console it works
but then windows app has console that pops up, which is not
acceptable. This too may have been fixed in the latest ldc.
