What's up with GDC?

Joerg Joergonson via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Jun 11 21:19:33 PDT 2016 

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.

More information about the Digitalmars-d-learn mailing list