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

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)

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

On Saturday, 11 June 2016 at 14:10:07 UTC, Johan Engelen wrote:
> On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:
> [... a lot ...]
>
> This looks like a nice writeup Mike, could you get this on the Wiki or somewhere more permanent where people can find it?
>
> -Johan

I've been meaning to slap together a tutorial on this for my long-neglected Learning D blog. once I finally get around to it, I'll add a link to the Wiki.

On Sunday, 12 June 2016 at 01:51:05 UTC, Joerg Joergonson wrote:
>
> Well, it's definitely not as simple as you make it out to be. I have tried all kinds of combinations of libs and settings and nothing works. If it's not one error it's another and it becomes hard to know exactly what is going on because the people who created these applications didn't have the forethought to give meaningful error messages.
>
> I believe the main problem now is that ldc is not linking phobo's or runtime or whatever because I get all kinds of weird export issues.
>
>
> with x86 ldc I get
>
> Error: module libsmBase is in file 'libsmBase.d' which cannot be read.
>
> The module though is actually mBase and it is in libs\mBase. It removing the directory.
>
> From the build:
>
> echo libs\mBase.d >"Win32\Debug LDC\Test.build.rsp"
>
> So, not sure if the error is just leaving out the '\' or what. Irregardless, please don't act like all this is my problem because most of it is due to crappy design and forethought.

This is a compiler error, not a linker error. "module foo is in file 'foo.d'" is the error you normally see when you've got a problem with your import path, or imported the wrong module name. Obviously, there's an issue here with the directory name being pushed onto the module name, but I can't even begin to guess why that happened. I assume you've imported mBase in another module. What was your import statement? Do you have a module declaration in mBase.d?

And I know you're frustrated, but please don't blame 'crappy design and forethought'. Plenty of people are using these tools just fine. That doesn't mean that there won't be bugs in them, or that they are implemented to the point that someone unfamiliar with them can use them out of the box. VisualD is developed by one person in his spare time. The LDC team is also small and work in their spare time. I think they've done a great job getting as far as they have. Once we figure out what your issue is, then you should be golden.

>
> Maybe I am suppose to include the subdirs in my project in visual studio/D and the error message simply cannot find the modules? But how am I suppose to know that with an illogical error message like what is above?

That's not an illogical error message. It's coming from the DMD front end, which all of the major D compilers share. Anytime you see it, it means you've got an issue with your import path. I've never seen the specific error you've got, where the directory name is merged with the file name. That *is* weird, but the error message itself is normally very useful.

>
> DMD works fine BTW. GDC and LDC should be a drop in replacement. Not a totally new setup that has it's own set of problems. I'm sure I'm not the only one put off by the compounding of problems when using D.

I think that's reasonable. All three compilers share the same fronted, but beyond that, they are quite different. IIRC, LDC does recognize some DMD switched, and there is a tool called GDMD that allows you to invoke GDC as if you were invoking DMD, but you can't expect the compilers to be drop-in replacements for each other. GDC has to fit in with the GCC ecosystem, which means it accepts a number of command line options that DMD does not support, and any that are specific to D must be consistent with other GCC tools in format. LDC also is a completely different tool. There will always be differences that prevent them from being interchangeable, which is why we have build tools and IDEs to hide the differences from us.

On Sunday, 12 June 2016 at 03:11:14 UTC, Mike Parker wrote:

> I think that's reasonable. All three compilers share the same

Sorry, I mean I *don't* think that's reasonable.

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.

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

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

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

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.

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

On Sunday, 12 June 2016 at 03:11:14 UTC, Mike Parker wrote:
> On Sunday, 12 June 2016 at 01:51:05 UTC, Joerg Joergonson wrote:
>>
>> DMD works fine BTW. GDC and LDC should be a drop in replacement. Not a totally new setup that has it's own set of problems. I'm sure I'm not the only one put off by the compounding of problems when using D.
>
> [...]
> IIRC, LDC does recognize some DMD switches, and there is a tool called GDMD that allows you to invoke GDC as if you were invoking DMD, but you can't expect the compilers to be drop-in replacements for each other.

LDC has LDMD2 that accepts DMD-like parameters.

LDMD2 calls LDC2. Compiler options not recognized by LDMD2 are passed straight to LDC2, so you can pass LDC-specific options to LDMD2 too.

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
>
> So ldc parses things differently than dmd... I imagine this is a bug!

That, or you are comparing different D language versions.

The D language is evolving: different DMD compiler versions may treat the same code differently.
>  ldc2 --version
LDC - the LLVM D compiler (683d9e):
  based on DMD v2.071.1 and LLVM 3.5.2svn-r255994
                             ^^^^^^^
So this LDC version is compatible with the D-language spec of DMD 2.071.
When comparing compilers on code they accept/decline, you have to compare the same language spec.

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
> 
> 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

The first one is a pre-alpha (!) version.
The second one is our latest released version, which is the one I recommend you to use.

If you want your bugs to be noted and fixed, you should try that test version and report bugs. That's kind of what you are doing now, so thanks ;)  Of course, clarity in reporting is important to get bugs fixed...