www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's up with GDC?

reply Joerg Joergonson <JJoergonson gmail.com> writes:
version 2.062? 2.066.1?

arm-linux-gnueabi 	
arm-linux-gnueabihf

?

I remember a year ago when I tried D for the first time I 
downloaded both gdc and ldc and everything just worked and each 
install was just like dmd!  Now it seems like a step backwards 
and I'm not sure what is going on.  arm-linux-genuabi? 
arm-linux-gnueableihfqueridsofeyfh?  
aifh-fkeif-fjjjjjjjj-fdsskjhfkjfafaaaaaa?

Is D dead?  If DMD is the reference compiler and can't be used 
for production code... and gdc is about 1000 versions out of 
date... and ldc requires building from sources(actually I didn't 
have too much trouble with installing it but it doesn't work with 
my libs because of the crappy coff issues that D has had since 
birth(it's like a tumor)).

`Windows users should replace arm-gdcproject-linux-gnueabi-gdc 
with arm-gdcproject-linux-gnueabi-gdc.exe.`

Why so many hoops to jump through? D is making me feel like a 
poodle!
Jun 10 2016
parent reply Johan Engelen <j j.nl> writes:
On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote:

 
  arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh?  
 aifh-fkeif-fjjjjjjjj-fdsskjhfkjfafaaaaaa?


Rofl!


 and ldc requires building from sources(actually I didn't have 
 too much trouble with installing it but it doesn't work with my 
 libs because of the crappy coff issues that D has had since 
 birth(it's like a tumor)).


Why do you have to build from sources? Any details about the 
problems you see?

Thanks,
   Johan
Jun 10 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote:

 On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote:

 
  arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh?  
 aifh-fkeif-fjjjjjjjj-fdsskjhfkjfafaaaaaa?


 Rofl!


 and ldc requires building from sources(actually I didn't have 
 too much trouble with installing it but it doesn't work with 
 my libs because of the crappy coff issues that D has had since 
 birth(it's like a tumor)).


 Why do you have to build from sources? Any details about the 
 problems you see?

 Thanks,
   Johan


Well, the post was a bit incoherent because getting all this 
stuff working is. I was searching for ldc and ran across some web 
site that had only the sources(same for gdc).

The point of it all is that things seem to be a bit 
discombobulated and make D look bad.  Professions won't use D if 
it can't be used professionally(not that I'm a pro, just saying).

Why isn't there a proper binaries for ldc and gdc that work out 
of the box like dmd?  There used to be. What's up with all this 
arm-linux-genuabi crap? When one opens up the archive all the 
files are named that way too.  There is no explanation of what 
that means. Did some kid write this stuff in his basement or is 
this suppose to be serious? Do people think about the end user 
when creating this stuff or is it just a eureka moment 
"Lightbulb: Lets create some spaghetti!".

I would have thought things would have gotten easier and more 
logical but that doesn't seem to be the case.
Jun 10 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote:

 On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote:

   [...]


 Well, the post was a bit incoherent because getting all this 
 stuff working is. I was searching for ldc and ran across some 
 web site that had only the sources(same for gdc).

 The point of it all is that things seem to be a bit 
 discombobulated and make D look bad.  Professions won't use D 
 if it can't be used professionally(not that I'm a pro, just 
 saying).

 Why isn't there a proper binaries for ldc and gdc that work out 
 of the box like dmd?  There used to be. What's up with all this 
 arm-linux-genuabi crap? When one opens up the archive all the 
 files are named that way too.  There is no explanation of what 
 that means. Did some kid write this stuff in his basement or is 
 this suppose to be serious? Do people think about the end user 
 when creating this stuff or is it just a eureka moment 
 "Lightbulb: Lets create some spaghetti!".

 I would have thought things would have gotten easier and more 
 logical but that doesn't seem to be the case.


The official download page is http://dlang.org/download.html (ldc 
download can be found from there) - please let us know if you 
find other outdated pages.

You can even use the official install script for ldc and gdc too 
:)
Jun 10 2016
prev sibling next sibling parent David Nadlinger <code klickverbot.at> writes:
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote:

 Well, the post was a bit incoherent because getting all this 
 stuff working is. I was searching for ldc and ran across some 
 web site that had only the sources(same for gdc).
 […]
 Why isn't there a proper binaries for ldc and gdc that work out 
 of the box like dmd?


LDC binaries exist and work out of the box – just extract them 
anywhere and you are set. Have a look at the official release 
list: https://github.com/ldc-developers/ldc/releases

I'm not sure what other website you came across; maybe there are 
some links that need fixing?

  — David
Jun 10 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote:

 Why isn't there a proper binaries for ldc and gdc that work out 
 of the box like dmd?  There used to be. What's up with all this 
 arm-linux-genuabi crap?


Those are proper binaries that work out of the box on different 
platforms.

Alas Windows doesn't have prebuilt binaries for gdc targeting 
Windows. Weird, the Windows binaries there generate ARM binaries 
(for phones and stuff).

LDC has Win32 builds though:
https://github.com/ldc-developers/ldc/releases/download/v1.0.0/ldc2-1.0.0-win32-msvc.zip
Jun 10 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Friday, 10 June 2016 at 21:33:58 UTC, Adam D. Ruppe wrote:

 On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote:

 Why isn't there a proper binaries for ldc and gdc that work 
 out of the box like dmd?  There used to be. What's up with all 
 this arm-linux-genuabi crap?


 Those are proper binaries that work out of the box on different 
 platforms.

 Alas Windows doesn't have prebuilt binaries for gdc targeting 
 Windows. Weird, the Windows binaries there generate ARM 
 binaries (for phones and stuff).

 LDC has Win32 builds though:
 https://github.com/ldc-developers/ldc/releases/download/v1.0.0/ldc2-1.0.0-win32-msvc.zip


The problem I'm getting with ldc, using your simpledisplay, is 
that the libs aren't loading due to the wrong format. It's the 
omf vs coff thing or whatever, I guess... I didn't feel like 
messing with it right now(later I'll need both x86 and x64 libs 
that work with dmd, ldc, and gdc). But yea, ldc basically worked 
similar to dmd, but not gdc.
Jun 10 2016
next sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote:

 The problem I'm getting with ldc, using your simpledisplay, is 
 that the libs aren't loading due to the wrong format. It's the 
 omf vs coff thing or whatever, I guess...


How do you mean that? LDC/MSVC uses COFF, and there should be no 
issues with linking against any external libraries you might 
need. Knowing Adam, though, simpledisplay probably only depends 
on the Win32 API, so I'm not sure where the issue would be in the 
first place.

Unless, of course, you are referring to linking an LDC executable 
against a simpledisplay library built with DMD – the different D 
compilers are not ABI-compatible, and will not be for the 
foreseeable future.

  — David
Jun 10 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 11 June 2016 at 01:04:28 UTC, David Nadlinger wrote:

 Knowing Adam, though, simpledisplay probably only depends on 
 the Win32 API, so I'm not sure where the issue would be in the 
 first place.


It also uses opengl32.lib that could be a problem. I offer the 
.omf file on my github for people to download... but with ldc 
you'd want to use whatever is packaged there (the Microsoft 
ones?).

Or compile with -version=without_opengl and that might work too 
(or the LDC translation of that). Grab the newest version btw 
because I just noticed a bug in that version.
Jun 10 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote:

 The problem I'm getting with ldc, using your simpledisplay, is 
 that the libs aren't loading due to the wrong format.



What's the exact message and what did you do? The opengl32.lib I 
have on my github is for dmd 32 bit, ldc uses the Microsoft one I 
think so you shouldn't need anything else.
Jun 10 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:

 On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote:

 The problem I'm getting with ldc, using your simpledisplay, is 
 that the libs aren't loading due to the wrong format.



 What's the exact message and what did you do? The opengl32.lib 
 I have on my github is for dmd 32 bit, ldc uses the Microsoft 
 one I think so you shouldn't need anything else.


It just says the format is invalid. I used the one you supplied 
in the package and never worried about it. I'll try some other 
libs when I get a chance.

BTW I make your code a bit better with resizing


case WM_SIZING:
     goto size_changed;
break;
case WM_ERASEBKGND: 				
	break;


Handling the erase background prevents windows from clearing the 
window, even with open GL. This allows resizing the window to 
still show the content. The only problem with it is that it seems 
the opengl code shifts up and down as the resize happens... It is 
probably an issue with the size change updates. It's pretty minor 
though and better than what it was(when I'd resize the window 
would go white and stay white as long as mouse was moving)

The specific errors are

opengl32.lib : warning LNK4003: invalid library format; library 
ignored
glu32.lib : warning LNK4003: invalid library format; library 
ignored
Jun 10 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:

 On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:



 What's the exact message and what did you do? The opengl32.lib 
 I have on my github is for dmd 32 bit, ldc uses the Microsoft 
 one I think so you shouldn't need anything else.


 It just says the format is invalid. I used the one you supplied 
 in the package and never worried about it. I'll try some other 
 libs when I get a chance.


OpenGL32.lib and glu32.lib are part of the Windows SDK. Assuming 
you've got VS 2015 installed, they should be part of the 
installation and should be available out of the box. Adam's lib 
is solely for use with OPTLINK when compiling with DMD using the 
default -m32 on Windows, since DMD does not ship with the opengl 
lib. When compiling with -m32mscoff or -m64, it will use Visual 
Studios libraries.
Jun 10 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Saturday, 11 June 2016 at 05:12:56 UTC, Mike Parker wrote:

 On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson 
 wrote:

 On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:



 What's the exact message and what did you do? The 
 opengl32.lib I have on my github is for dmd 32 bit, ldc uses 
 the Microsoft one I think so you shouldn't need anything else.


 It just says the format is invalid. I used the one you 
 supplied in the package and never worried about it. I'll try 
 some other libs when I get a chance.


 OpenGL32.lib and glu32.lib are part of the Windows SDK. 
 Assuming you've got VS 2015 installed, they should be part of 
 the installation and should be available out of the box. Adam's 
 lib is solely for use with OPTLINK when compiling with DMD 
 using the default -m32 on Windows, since DMD does not ship with 
 the opengl lib. When compiling with -m32mscoff or -m64, it will 
 use Visual Studios libraries.


That's not true unless I'm not suppose to import them directly. 
When I switch to 64-bit build I get same errors. Basically only 
dmd x86 works.

It could be my setup.

This is EXACTLY what anyone who is doing this sort of stuff needs 
to know:

1. How to tell the difference between different libs and what 
kind of libs are required for what kind of compiler and build.

       x86    x64
DMD    .      .
LDC    .      .
GDC    .      .

Please fill in the table for windows, linux, etc.

If I know this information then it is at least easy to make sure 
I have matching socks. Else it's kinda pointless to put on shoes?


2. How does the D build system fetch the libs? It uses the 
sci.ini path? What about Visual D?

Just because I have the correct stuff from 1 doesn't mean it is 
in the "correct" place.

Where does D look for these? I assume in the "libs" directory?
    pragma(lib, "opengl32");
    pragma(lib, "glu32");

3. How to get different compilers and versions to play along? I 
would eventually like to build for win/lin/osx for both x64 and 
x86.

Without these 3 ingredients, everything is futile!


I am using Visual D, BTW. It seems to have a lot of stuff setup 
by default but I haven't went in and messed with the settings 
much.
Jun 10 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 11 June 2016 at 06:22:27 UTC, Joerg Joergonson wrote:

 OpenGL32.lib and glu32.lib are part of the Windows SDK. 
 Assuming you've got VS 2015 installed, they should be part of 
 the installation and should be available out of the box. 
 Adam's lib is solely for use with OPTLINK when compiling with 
 DMD using the default -m32 on Windows, since DMD does not ship 
 with the opengl lib. When compiling with -m32mscoff or -m64, 
 it will use Visual Studios libraries.


 That's not true unless I'm not suppose to import them directly. 
 When I switch to 64-bit build I get same errors. Basically only 
 dmd x86 works.


It's true if everything is configured properly.



 1. How to tell the difference between different libs and what 
 kind of libs are required for what kind of compiler and build.

       x86    x64
 DMD    .      .
 LDC    .      .
 GDC    .      .

 Please fill in the table for windows, linux, etc.


On Windows/Mac/FreeBSD, if you know how to configure libraries 
for gcc, then you know how to configure them with DMD. You 
install the packages you need from your package manager, they are 
installed by default in the appropriate system paths, and when 
DMD invokes the system linker they will be found.

Windows is only problematic because there's no such thing as a 
system linker, nor are there any standard system paths for 
libraries. Given the following command line:

dmd foo.d user32.lib

The compiler will invoke OPTLINK, which it ships with. This 
guarantees that you always have a linker if DMD is installed. You 
will find several Win32 libraries in the dmd2/windows/lib 
directory. They are all a in OMF format for OPTLINK and they are 
all a bit outdated. With the above command line, the user32.lib 
in that directory will be used. If you need a Win32 system 
library that does not ship with DMD (such as OpenGL32.lib) you 
will need to provide it yourself in the OMF format to use it with 
OPTLINK.

Add either the -m32mscoff or -m64 command line switch and DMD 
will invoke whichever Microsoft linker it is configured to call, 
meaning it will no longer use the libraries that ship with DMD. 
If you've installed one of paid versions of VS, or one of the 
Community Editions, all of the Win32 libraries will be installed 
as well. If you're using one of the VS Express versions, you'll 
need a Windows SDK installed to have the Win32 libraries.

 2. How does the D build system fetch the libs? It uses the 
 sci.ini path? What about Visual D?


Yes, on Windows, sc.ini is where the library paths are 
configured. If you installed DMD manually, or used the installer 
but installed Visual Studio after, then you will need to edit 
sc.ini to make sure the paths point to the proper VS locations. 
If run the DMD installer *after* installing Visual Studio, the 
installer will configure sc.ini for you. I recommend you take 
that approach. It just works.

On other systems, dmd.conf is used to configure the location of 
libphobos2, but system libraries are on the system path (just as 
when using gcc).


 Where does D look for these? I assume in the "libs" directory?
    pragma(lib, "opengl32");
    pragma(lib, "glu32");


On Windows, it looks on the path configured in sc.ini or whatever 
import path you have provided on the command line with -I, just 
as it does with any libraries you pass on the command line. So 
that means that compiling without -m32mscoff or -m64, it looks 
win the dmd2/windows/lib directory. Since opengl32 and glu32 do 
not ship with DMD, it will not find them there. So you either 
need to put COFF format libs there or tell the compiler where to 
find them with -I. With -m32mscoff or -m64, it looks for the 
Microsoft version of those libraries in the Visual Studio or 
Windows SDK installation, which you should have configured in 
sc.ini as I explained above.

On other systems, the OpenGL libraries are found on the system 
library path.


 3. How to get different compilers and versions to play along? I 
 would eventually like to build for win/lin/osx for both x64 and 
 x86.


On Windows, Just make sure you provide any third-party libraries 
you need, along with any system libraries you need that DMD does 
not ship with, in the OMF format when using OPTLINK on Windows 
and tell DMD where to find them. When using the MS toolchain, the 
system libraries are all there, so you need not provide any. 
You'll just need to make sure any third-party libraries are in 
the COFF format (preferably compiled with the same version of 
Visual Studio you are using to link your D programs).

On Linuux and OSX, just make sure the dev packages of any 
libraries you need are installed. You do need to account for 
different libray names (e.g. Openg32.lib on Windows vs. libopengl 
elswhere, so your pragmas above should include '32' in the name 
only on Windows).

Alternatively, you might try one of the dynamic bindings[1] to a 
library you need, such as DerelictGL3. Then there is no link time 
dependency, as the shared libraries are loaded at runtime. On 
Windows, that completely eliminates the COFF vs. OMF issues. As 
long as the DLLs match your executable's architecture (32-bit vs. 
64-bit), then it doesn't matter what compiler was used to create 
them when loading them at runtime.

 I am using Visual D, BTW. It seems to have a lot of stuff setup 
 by default but I haven't went in and messed with the settings 
 much.


Well, when it invokes DMD, the compiler uses whatever you've 
configured in sc.ini for the system libraries. Anything else you 
can configure in Visual D's project settings.
Jun 11 2016
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:


 it looks win the dmd2/windows/lib directory. Since opengl32 and 
 glu32 do not ship with DMD, it will not find them there. So you 
 either need to put COFF format libs there or tell the compiler


Obviously, I meant 'OMF format' here.
Jun 11 2016
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:


 Alternatively, you might try one of the dynamic bindings[1] to 
 a library you need, such as DerelictGL3. Then there is no link


[1] https://github.com/DerelictOrg
Jun 11 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
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
Jun 11 2016
parent Mike Parker <aldacron gmail.com> writes:
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.
Jun 11 2016
prev sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:

 On Saturday, 11 June 2016 at 06:22:27 UTC, Joerg Joergonson 
 wrote:

 [...]


 That's not true unless I'm not suppose to import them 
 directly. When I switch to 64-bit build I get same errors. 
 Basically only dmd x86 works.


 It's true if everything is configured properly.



 1. How to tell the difference between different libs and what 
 kind of libs are required for what kind of compiler and build.

       x86    x64
 DMD    .      .
 LDC    .      .
 GDC    .      .

 Please fill in the table for windows, linux, etc.


 On Windows/Mac/FreeBSD, if you know how to configure libraries 
 for gcc, then you know how to configure them with DMD. You 
 install the packages you need from your package manager, they 
 are installed by default in the appropriate system paths, and 
 when DMD invokes the system linker they will be found.

 Windows is only problematic because there's no such thing as a 
 system linker, nor are there any standard system paths for 
 libraries. Given the following command line:

 dmd foo.d user32.lib

 The compiler will invoke OPTLINK, which it ships with. This 
 guarantees that you always have a linker if DMD is installed. 
 You will find several Win32 libraries in the dmd2/windows/lib 
 directory. They are all a in OMF format for OPTLINK and they 
 are all a bit outdated. With the above command line, the 
 user32.lib in that directory will be used. If you need a Win32 
 system library that does not ship with DMD (such as 
 OpenGL32.lib) you will need to provide it yourself in the OMF 
 format to use it with OPTLINK.

 Add either the -m32mscoff or -m64 command line switch and DMD 
 will invoke whichever Microsoft linker it is configured to 
 call, meaning it will no longer use the libraries that ship 
 with DMD. If you've installed one of paid versions of VS, or 
 one of the Community Editions, all of the Win32 libraries will 
 be installed as well. If you're using one of the VS Express 
 versions, you'll need a Windows SDK installed to have the Win32 
 libraries.

 2. How does the D build system fetch the libs? It uses the 
 sci.ini path? What about Visual D?


 Yes, on Windows, sc.ini is where the library paths are 
 configured. If you installed DMD manually, or used the 
 installer but installed Visual Studio after, then you will need 
 to edit sc.ini to make sure the paths point to the proper VS 
 locations. If run the DMD installer *after* installing Visual 
 Studio, the installer will configure sc.ini for you. I 
 recommend you take that approach. It just works.

 On other systems, dmd.conf is used to configure the location of 
 libphobos2, but system libraries are on the system path (just 
 as when using gcc).


 Where does D look for these? I assume in the "libs" directory?
    pragma(lib, "opengl32");
    pragma(lib, "glu32");


 On Windows, it looks on the path configured in sc.ini or 
 whatever import path you have provided on the command line with 
 -I, just as it does with any libraries you pass on the command 
 line. So that means that compiling without -m32mscoff or -m64, 
 it looks win the dmd2/windows/lib directory. Since opengl32 and 
 glu32 do not ship with DMD, it will not find them there. So you 
 either need to put COFF format libs there or tell the compiler 
 where to find them with -I. With -m32mscoff or -m64, it looks 
 for the Microsoft version of those libraries in the Visual 
 Studio or Windows SDK installation, which you should have 
 configured in sc.ini as I explained above.

 On other systems, the OpenGL libraries are found on the system 
 library path.


 3. How to get different compilers and versions to play along? 
 I would eventually like to build for win/lin/osx for both x64 
 and x86.


 On Windows, Just make sure you provide any third-party 
 libraries you need, along with any system libraries you need 
 that DMD does not ship with, in the OMF format when using 
 OPTLINK on Windows and tell DMD where to find them. When using 
 the MS toolchain, the system libraries are all there, so you 
 need not provide any. You'll just need to make sure any 
 third-party libraries are in the COFF format (preferably 
 compiled with the same version of Visual Studio you are using 
 to link your D programs).

 On Linuux and OSX, just make sure the dev packages of any 
 libraries you need are installed. You do need to account for 
 different libray names (e.g. Openg32.lib on Windows vs. 
 libopengl elswhere, so your pragmas above should include '32' 
 in the name only on Windows).

 Alternatively, you might try one of the dynamic bindings[1] to 
 a library you need, such as DerelictGL3. Then there is no link 
 time dependency, as the shared libraries are loaded at runtime. 
 On Windows, that completely eliminates the COFF vs. OMF issues. 
 As long as the DLLs match your executable's architecture 
 (32-bit vs. 64-bit), then it doesn't matter what compiler was 
 used to create them when loading them at runtime.

 I am using Visual D, BTW. It seems to have a lot of stuff 
 setup by default but I haven't went in and messed with the 
 settings much.


 Well, when it invokes DMD, the compiler uses whatever you've 
 configured in sc.ini for the system libraries. Anything else 
 you can configure in Visual D's project settings.


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.

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?

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.
Jun 11 2016
next sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
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.
Jun 11 2016
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jun 11 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
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.
Jun 11 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
Jun 11 2016
parent Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 12 June 2016 at 05:08:12 UTC, Mike Parker wrote:

 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



1. Your mixing up my problems(maybe my fault, but that's not the 
point). The phobo's errors are

simpledisplay.obj : error LNK2001: unresolved external symbol 
__D10TypeInfo_w6__initZ
winmain.obj : error LNK2019: unresolved external symbol 
__D4core6memory2GC7collectFNbZv (nothrow void 
core.memory.GC.collect()) referenced in function __Dmain
winmain.obj : error LNK2019: unresolved external symbol 
__d_run_main referenced in function _main
winmain.obj : error LNK2001: unresolved external symbol 
__D4core7runtime12__ModuleInfoZ
LINK : error LNK2001: unresolved external symbol 
__load_config_used
../ldc2/bin/../lib64\phobos2-ldc.lib : warning LNK4272: library 
machine type 'x64' conflicts with target machine type 'X86'
.../ldc2/bin/../lib64\druntime-ldc.lib : warning LNK4272: library 
machine type 'x64' conflicts with target machine type 'X86'

This happens only when I compile to x86. X64 works fine. The dir 
is the ldc dir, not mine. This suggests druntim-ldc.lib is x64 
and not x86. (As one can see from lib64, why it is being used 
instead of lib32 is beyond me... but I don't see that in any of 
my configurable settings)

The best I can tell is that ldc:

// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.

// The default group is required
default:
{
     // 'switches' holds array of string that are appends to the 
command line
     // arguments before they are parsed.
     switches = [
         "-I%%ldcbinarypath%%/../include/d/ldc",
         "-I%%ldcbinarypath%%/../include/d",
         "-L-L%%ldcbinarypath%%/../lib64",
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
     ];
};

i686-pc-windows-msvc:
{
     // 'switches' holds array of string that are appends to the 
command line
     // arguments before they are parsed.
     switches = [
         "-I%%ldcbinarypath%%/../include/d/ldc",
         "-I%%ldcbinarypath%%/../include/d",
         "-L-L%%ldcbinarypath%%/../lib32",
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
     ];
};

is defaulting to x64 and not using the lib32 dir like it should. 
Getting it to should lib32 should fix the compilation problem.

The -L/Entry thing did fix the x64 windows subsystem problem... 
so everything is working now for x64.

2. The type bug seems to be a change in dmd/ldc. It is an import 
issue. I used the same name as Adam and for some reason ldc 
imports his into my project and dmd does not. See his post for 
that.

3. There is definitely a bug in the latest ldc... Swapping 
binaries may be a bad thing to you but it's the only way I could 
quickly diagnose the problem. I'd rather pack a wound with mud 
then let someone bleed out and die because mud is unsanitary. It 
proves there is a problem with ldc since the "correct" 
installation doesn't work in the first place and simply swapping 
the binaries makes it work. (basic math here)
Jun 12 2016
prev sibling next sibling parent Johan Engelen <j j.nl> writes:
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.
Jun 12 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
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...
Jun 12 2016
parent Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 12 June 2016 at 09:11:09 UTC, Johan Engelen wrote:

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


Ok. Well, I didn't know I was using an alpha version. Two bugs I 
have:

1. Paths(imports to subdirs as explained in my other posts) are 
not correct. It seems to be dropping the last '\'. Probably a 
simple substring range bug. (e.g., 1..$-2 instead of 1..$-1). 
Since it works in the previous version, it shouldn't be too hard 
to diff on the modules path resolution code.

2. There seems to be an issue with the x86 libs not being 
correctly resolved. The default is to choose x64. When I compile 
for x86 it still uses them. Maybe a compiler switch is needed, 
but regardless this isn't good practice. -m32 is being passed, 
maybe this should select the 32-bit configuration?

If these are regressions then someone needs to be fired!!! If 
not, someone still needs to be fired! Or at least be forced to 
buy me a ham burger or something!
Jun 12 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:

 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:


It's probably the difference of the recent import rules bug fix. 
gamehelpers public imports simpledisplay, so its ScreenPainter 
will be visible there too.

You can probably just exclude it from the import by doing 
selective:

import arsd.gamehelpers : create2dWindow;

and comma list anything else you use from there (probably just 
OpenGlTexture, it is a small module).


But yeah, weird that it is different, but this was REALLY 
recently changed so if the release differs by just one month in 
version it could account for the difference.


 Although, If I set the subsystem to windows I then get the error


There's another MSFT library needed there passing 
`-L/entry:mainCRTStartup` to the build should do it.

dmd 32 bit has its own library so it isn't needed there, but dmd 
64 bit and ldc both I believe need the entry point.
Jun 12 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 12 June 2016 at 12:38:25 UTC, Adam D. Ruppe wrote:

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

 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:


 It's probably the difference of the recent import rules bug 
 fix. gamehelpers public imports simpledisplay, so its 
 ScreenPainter will be visible there too.

 You can probably just exclude it from the import by doing 
 selective:

 import arsd.gamehelpers : create2dWindow;

 and comma list anything else you use from there (probably just 
 OpenGlTexture, it is a small module).


 But yeah, weird that it is different, but this was REALLY 
 recently changed so if the release differs by just one month in 
 version it could account for the difference.


 Although, If I set the subsystem to windows I then get the 
 error


 There's another MSFT library needed there passing 
 `-L/entry:mainCRTStartup` to the build should do it.

 dmd 32 bit has its own library so it isn't needed there, but 
 dmd 64 bit and ldc both I believe need the entry point.



Thanks. It worked! BTW, when I compile a simple project with your 
simpledisplay it takes up around 300MB(for ldc, 400 for dmd) and 
uses about 15% cpu. Basically just a modified example that draws 
some images which maybe take up 20MB total. Any ideas why it's 
taking up so much space and cpu? What's it doing on your machine?
Jun 12 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:

 BTW, when I compile a simple project with your simpledisplay it 
 takes up around 300MB(for ldc, 400 for dmd) and uses about 15% 
 cpu.


What's your code? The library itself does fairly little so the 
time probably depends on your draw loop or timer settings (though 
it did have a memory leak until recently, it wasn't apparent 
until something had been running for a really long time - I use 
it in my day-to-day terminal emulator, so I have like 40 copies 
of the process running for months on end here...)


I'm leaving in 2 minutes for church btw so I might not answer you 
for about 5 hours when I'm back at the computer.
Jun 12 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 12 June 2016 at 13:23:26 UTC, Adam D. Ruppe wrote:

 On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:

 BTW, when I compile a simple project with your simpledisplay 
 it takes up around 300MB(for ldc, 400 for dmd) and uses about 
 15% cpu.


 What's your code? The library itself does fairly little so the 
 time probably depends on your draw loop or timer settings 
 (though it did have a memory leak until recently, it wasn't 
 apparent until something had been running for a really long 
 time - I use it in my day-to-day terminal emulator, so I have 
 like 40 copies of the process running for months on end here...)


 I'm leaving in 2 minutes for church btw so I might not answer 
 you for about 5 hours when I'm back at the computer.


Well, it's about the same when I comment all my code out! It 
drops about 30 megs and a percent or two but still quite large.

When I remove all code, it is 2MB in size and 0 cpu(I just use 
Sleep to keep it from terminating).

When I try to use a sleep before the event loop to and just call 
create2dWindow, I get

Error: undefined identifier 'Sleep' in module 'core.thread', did 
you mean function 'Sleep'?		

Which godly in it's descriptive powers, right?

The code added is

		import core.thread;
		core.thread.Sleep(10000);

which is the same code I use in main() which works(worked)

		import core.thread : Sleep;
		Sleep(10000);

works though. Basically keeping the event loop uses around 12% 
cpu and 12MB of memory. Adding in my code, which simply uses your 
png to load some images and display them balloons it to 400MB. 
The exe is only 7MB in size.

So, I believe it is your code. The event loop is using quite a 
bit of cpu even when not "doing" anything(haven't look at it 
behind the scenes though).

The memory is probably from loading the images, possibly doubling 
all the images to powers of 2 might explain some of the bloat. I 
have a few large images that when uncompressed might be 20-40MB 
total and several smaller ones, probably insignificant. Shouldn't 
add up to 300MB though.

Once I get further in I'll try to see whats going on. I haven't 
noticed it leaking memory though.

Do you know if there is a way to get the largest used memory 
chunks and what is using them? That might tell the story!
Jun 12 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:

 Error: undefined identifier 'Sleep' in module 'core.thread', 
 did you mean function 'Sleep'?


It is supposed to be `Thread.sleep(10000.seconds);`

I'm pretty sure the capital Sleep() is supposed to be private 
(that is the OS-specific Windows api call).



 Basically keeping the event loop uses around 12% cpu and 12MB 
 of memory.


That's weird, it just sleeps until a message comes in from the 
OS. On my computer, programs sit at 0% like you'd expect, and my 
guitest program (which has text areas, buttons, menu, etc) eats 
~1.7 MB, both 32 and 64 bit versions.

Are you running some other program that might be sending a lot of 
broadcast messages?


 Do you know if there is a way to get the largest used memory 
 chunks and what is using them? That might tell the story!


idk
Jun 13 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Monday, 13 June 2016 at 16:46:38 UTC, Adam D. Ruppe wrote:

 On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:

 Error: undefined identifier 'Sleep' in module 'core.thread', 
 did you mean function 'Sleep'?


 It is supposed to be `Thread.sleep(10000.seconds);`

 I'm pretty sure the capital Sleep() is supposed to be private 
 (that is the OS-specific Windows api call).


Ok, I tried both and Sleep was the one that worked for some odd 
ball reason.  Then it seemed to stop working I think(I tried it 
in a different spot)... maybe user error.


 Basically keeping the event loop uses around 12% cpu and 12MB 
 of memory.


 That's weird, it just sleeps until a message comes in from the 
 OS. On my computer, programs sit at 0% like you'd expect, and 
 my guitest program (which has text areas, buttons, menu, etc) 
 eats ~1.7 MB, both 32 and 64 bit versions.

 Are you running some other program that might be sending a lot 
 of broadcast messages?


Not that I know of. I haven't tried running it outside VS though 
so it might be doing something weird. I'll investigate further 
when I get a chance and get further down the road.

About the WM size thing, I haven't had a problem with it except 
for the weird vertical shifting. It doesn't use any more cpu when 
constantly resizing.
Jun 13 2016
parent Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Monday, 13 June 2016 at 20:21:28 UTC, Joerg Joergonson wrote:

 Are you running some other program that might be sending a lot 
 of broadcast messages?


 Not that I know of. I haven't tried running it outside VS 
 though so it might be doing something weird. I'll investigate 
 further when I get a chance and get further down the road.


It's often useful to attach a sampling profiler when the process 
is eating CPU. It should tell you what's going on at a glance.

I believe VS has a sampling profiler built in, but it most likely 
won't demangle D symbols, so the function names will be a bit 
hard to read.
Jun 14 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jun 11 2016
next sibling parent Mike Parker <aldacron gmail.com> writes:
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.
Jun 11 2016
prev sibling parent Johan Engelen <j j.nl> writes:
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.
Jun 12 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:

 BTW I make your code a bit better with resizing

 case WM_SIZING:
     goto size_changed;
 break;


I left that out intentionally because it lagged on my computer... 
so I wanted it to stay blank.

Maybe it can be made more efficient though.
Jun 13 2016
prev sibling parent reply Christophe Meessen via Digitalmars-d-learn writes:
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Real professionals won't have difficulties to find binaries for ldc: https:/=
/github.com/ldc-developers/ldc/releases

--
Bien cordialement,
Ch.Meessen


 Le 10 juin 2016 =C3=A0 22:30, Joerg Joergonson via Digitalmars-d-learn <di=


gitalmars-d-learn puremagic.com> a =C3=A9crit :

=20

 On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote:

 On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote:
 arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh?  aifh-fkeif-fjjjj=






jjjj-fdsskjhfkjfafaaaaaa?

=20
 Rofl!
=20

 and ldc requires building from sources(actually I didn't have too much t=






rouble with installing it but it doesn't work with my libs because of the cr=
appy coff issues that D has had since birth(it's like a tumor)).

=20
 Why do you have to build from sources? Any details about the problems you=




 see?

=20
 Thanks,
  Johan


=20
 Well, the post was a bit incoherent because getting all this stuff working=


 is. I was searching for ldc and ran across some web site that had only the s=
ources(same for gdc).

=20
 The point of it all is that things seem to be a bit discombobulated and ma=


ke D look bad.  Professions won't use D if it can't be used professionally(n=
ot that I'm a pro, just saying).

=20
 Why isn't there a proper binaries for ldc and gdc that work out of the box=


 like dmd?  There used to be. What's up with all this arm-linux-genuabi crap=
? When one opens up the archive all the files are named that way too.  There=
 is no explanation of what that means. Did some kid write this stuff in his b=
asement or is this suppose to be serious? Do people think about the end user=
 when creating this stuff or is it just a eureka moment "Lightbulb: Lets cre=
ate some spaghetti!".

=20
 I would have thought things would have gotten easier and more logical but t=


hat doesn't seem to be the case.

=20
=20
Jun 11 2016
parent Joerg Joergonson <JJoergonson gmail.com> writes:
On Saturday, 11 June 2016 at 16:04:45 UTC, Christophe Meessen 
wrote:

 Real professionals won't have difficulties to find binaries for 
 ldc: https://github.com/ldc-developers/ldc/releases


They also don't waste their time posting asinine comments.
Jun 11 2016