What's up with GDC?

Sat Jun 11 22:08:12 PDT 2016

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:

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

That's just asking for problems. You may get lucky and find that 
it works, but in general you don't want to go around swapping 
compiler executables like that.

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

So ScreenPainter is a *type* and not an instance of a type? That 
*should* be an error, no matter which compiler you use. You can't 
compare a type against null. What does that even mean? And if 
SimpleDisplay already defines the type, why have you redefined it?

Assuming ScreenPainter is a class, then:

if(ScreenPainter !is null) <-- Invalid

auto sp = new ScreenPainter;
if(sp !is null) <-- valid

>
> I can fix this by avoiding the import... but the point is that 
> it's different than dmd.

If ScreenPainter is defined as a type, it shouldn't ever compile. 
How have you defined it?

>
> So ldc parses things differently than dmd... I imagine this is 
> a bug!

LDC and DMD share the same front end, meaning they parse code the 
same. I really would like to see your code, particularly your 
definition of ScreenPainter.

> 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)>
> Which looks like it's not linking to runtime and/or phobos?

No, this has nothing to do with DRuntime, Phobos, or even D. It's 
a Windows thing. By default, when you compile a D program, you 
are creating a console system executable so your primary entry 
point is an extern(C) main function that is generated by the 
compiler. This initializes DRuntime, which in turn calls your D 
main function.

When using OPTLINK with DMD, the linker will ensure that the 
generated extern(C) main remains the entry point when you set the 
subsystem to Windows. When using the MS linker, this is not the 
case. The linker will expect WinMain to be the entry point when 
the subsystem is set to Windows. If you do not have a WinMain, 
you will see the error above. In order to keep the extern(C) main 
as your entry point, you have to pass the /ENTRY option to the 
linker (see[1]). LDC should provide a means for passing linker 
options. You can probably set in VisualD's project settings, but 
if there's no field for it then ldc2 --help may tell you what you 
need.

Alternatively, you can create a WinMain, but then you need to 
initialize DRuntime yourself. See [2], but ignore the .def file 
requirement since you are already setting the subsystem.

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

Then I would ask you to stop and think. There are a number of 
people using D without problems every day, including several 
companies. Obviously, they aren't having the same difficulties 
you are, else they wouldn't be successfully using D. You seem to 
be very quick to blame the tools rather than considering you 
might not fully understand how to use them. I don't mean that in 
a disparaging way. I've been there myself, trying to get 
something I wanted to use working and failing, then getting 
frustrated and blaming the tools. These days, I always blame 
yourself first. Sure, the tools sometimes have bugs and other 
issues, but more often than not it's because I'm using them the 
wrong way.

Right now, documentation on getting up to speed with LDC is 
sorely lacking. That's a valid criticism to make. For people who 
aren't familiar with it, or who aren't well versed in working 
with ahead of time compilers, whichever the case may be, it may 
not be the best choice for getting started with D. Since you seem 
to be having difficulties using LDC and since you've already told 
me that DMD is working for you, I strongly recommend that you use 
DMD instead for now. Once you are comfortable with D and the 
ecosystem, then look into using LDC.

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

LDC may have bugs, but I don't believe the problem you talked 
about above is one of them. I would really like to see all of the 
code you are trying to compile. The error you saw was what I 
would expect to see when trying to compare a type to null.

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

As I explained above, this is not a problem with LDC. The 
compile-link process in D is the same as it is in C and C++ and 
the generated Windows executables have the same requirements. As 
it is not D specific, there are a number of pages on the internet 
dealing with compiling and linking on Windows. Those will help 
you when using D compilers as well. You just have to adapt any 
compiler-specific command line arguments to the compiler you are 
using. I strongly recommend you familiarize yourself with the MS 
linker options, since it is prominent in the D toolchain on 
Windows now.

[1] https://msdn.microsoft.com/en-us/library/f9t8842e.aspx
[2] https://wiki.dlang.org/D_for_Win32