www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Compiling druntime on ldc2 - Win 8 x64

reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
Hi,

I hope this is appropriate for this section...
I have difficulties building ldc from the repository on Visual 
Studio 11 Win8 x64.
It compiles fine up to the point where ldc is invoked to compile 
the druntime.
this is an example failure: http://pastie.org/5854353 it fails to 
build druntime-ldc.vcxproj, druntime-ldc-debug.vcxproj and 
generate-headers.vcxproj, all while handling core.atomic.
Every attempt to compile atomic.d "by hand" results in ldc2.exe 
crashing with similar stack traces.

What actually flashes my naive view is the fact, that "real" is 
only used in a string, which seems to be accepted by the lexer as 
a declaration...

Except for many warnings, llvm, libconfig++ and ldc itself 
compiled just fine.

Greetings,
Sebastian
Jan 25 2013
parent reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 11:44:46 UTC, Sebastian Graf wrote:
 Hi,

 I hope this is appropriate for this section...
 I have difficulties building ldc from the repository on Visual 
 Studio 11 Win8 x64.
 It compiles fine up to the point where ldc is invoked to 
 compile the druntime.
 this is an example failure: http://pastie.org/5854353 it fails 
 to build druntime-ldc.vcxproj, druntime-ldc-debug.vcxproj and 
 generate-headers.vcxproj, all while handling core.atomic.
 Every attempt to compile atomic.d "by hand" results in ldc2.exe 
 crashing with similar stack traces.

 What actually flashes my naive view is the fact, that "real" is 
 only used in a string, which seems to be accepted by the lexer 
 as a declaration...

 Except for many warnings, llvm, libconfig++ and ldc itself 
 compiled just fine.

 Greetings,
 Sebastian
Yeah, so here we go, 15 minutes after posting... The compiler refused to parse an fp literal (1.0f), because ld_setll(longdouble*, __int64) failed. I don't have that much experience with assembler, but loading from [rsp] instead of [esp] in the second line of the definition in ldfpu.asm resolved the error for me. I hope this is nothing forbidden to do.
Jan 25 2013
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 25 January 2013 at 12:21:58 UTC, Sebastian Graf wrote:
 Yeah, so here we go, 15 minutes after posting... The compiler 
 refused to parse an fp literal (1.0f), because 
 ld_setll(longdouble*, __int64) failed. I don't have that much 
 experience with assembler, but loading from [rsp] instead of 
 [esp] in the second line of the definition in ldfpu.asm 
 resolved the error for me. I hope this is nothing forbidden to 
 do.
Please consider submitting a pull request containing the change on GitHub. The mixed use of esp and rsp in that file looks strange indeed, but I have never looked at that code before, so it would better be reviewed by Kai ( redstar). David
Jan 25 2013
parent reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 12:54:32 UTC, David Nadlinger wrote:
 On Friday, 25 January 2013 at 12:21:58 UTC, Sebastian Graf 
 wrote:
 Yeah, so here we go, 15 minutes after posting... The compiler 
 refused to parse an fp literal (1.0f), because 
 ld_setll(longdouble*, __int64) failed. I don't have that much 
 experience with assembler, but loading from [rsp] instead of 
 [esp] in the second line of the definition in ldfpu.asm 
 resolved the error for me. I hope this is nothing forbidden to 
 do.
Please consider submitting a pull request containing the change on GitHub. The mixed use of esp and rsp in that file looks strange indeed, but I have never looked at that code before, so it would better be reviewed by Kai ( redstar). David
Done. Yet somehow I still can't get it to link druntime. Both in release and debug mode I get http://msdn.microsoft.com/en-us/library/t0cs92zx(v=vs.110).aspx , because /O2 is combined with /RTC1, although the make file defs don't mix anything up. For the exact cl arguments see http://pastie.org/5856844.
Jan 25 2013
next sibling parent reply Kai Nacke <kai redstar.de> writes:
On 25.01.2013 14:55, Sebastian Graf wrote:
 Done. Yet somehow I still can't get it to link druntime. Both in release
 and debug mode I get
 http://msdn.microsoft.com/en-us/library/t0cs92zx(v=vs.110).aspx ,
 because /O2 is combined with /RTC1, although the make file defs don't
 mix anything up. For the exact cl arguments see http://pastie.org/5856844.
This is a problem for which I don't have a good solution yet. You can work around it if you change line 312 of runtime/CMakeLists.txt from COMPILE_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_RELEASE}" to COMPILE_FLAGS "${CMAKE_C_FLAGS}" Kai
Jan 25 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 25 January 2013 at 15:54:00 UTC, Kai Nacke wrote:
 This is a problem for which I don't have a good solution yet. 
 You can work around it if you change line 312 of 
 runtime/CMakeLists.txt from

         COMPILE_FLAGS "${CMAKE_C_FLAGS} 
 ${CMAKE_C_FLAGS_RELEASE}"

 to

         COMPILE_FLAGS "${CMAKE_C_FLAGS}"
Sorry for breaking the MSVC build, then. Is there a better way of enabling release mode in CMake? David
Jan 25 2013
parent reply Kai Nacke <kai redstar.de> writes:
On 25.01.2013 19:14, David Nadlinger wrote:
 On Friday, 25 January 2013 at 15:54:00 UTC, Kai Nacke wrote:
 This is a problem for which I don't have a good solution yet. You can
 work around it if you change line 312 of runtime/CMakeLists.txt from

         COMPILE_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_RELEASE}"

 to

         COMPILE_FLAGS "${CMAKE_C_FLAGS}"
Sorry for breaking the MSVC build, then. Is there a better way of enabling release mode in CMake? David
I had already committed a solution if I would know one. Kai
Jan 25 2013
parent reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 18:25:37 UTC, Kai Nacke wrote:
 On 25.01.2013 19:14, David Nadlinger wrote:
 On Friday, 25 January 2013 at 15:54:00 UTC, Kai Nacke wrote:
 This is a problem for which I don't have a good solution yet. 
 You can
 work around it if you change line 312 of 
 runtime/CMakeLists.txt from

        COMPILE_FLAGS "${CMAKE_C_FLAGS} 
 ${CMAKE_C_FLAGS_RELEASE}"

 to

        COMPILE_FLAGS "${CMAKE_C_FLAGS}"
Sorry for breaking the MSVC build, then. Is there a better way of enabling release mode in CMake? David
I had already committed a solution if I would know one. Kai
The workaround works like a charm... But I had to checkout ldc-merge-2.061 to get the libraries to work. That caused me minor headaches, but now I'm aware of what are the responsiblities (such as x64 support) of which repository... I can now INSTALL it, building a hello world app fails however due to linker errors in std.math, probably because I forgot to patch. I realize now that I should have checked out ldc-merge-2.061-2.
Jan 25 2013
parent reply Kai Nacke <kai redstar.de> writes:
On 25.01.2013 19:31, Sebastian Graf wrote:
 On Friday, 25 January 2013 at 18:25:37 UTC, Kai Nacke wrote:

 The workaround works like a charm... But I had to checkout
 ldc-merge-2.061 to get the libraries to work. That caused me minor
 headaches, but now I'm aware of what are the responsiblities (such as
 x64 support) of which repository...
 I can now INSTALL it, building a hello world app fails however due to
 linker errors in std.math, probably because I forgot to patch. I realize
 now that I should have checked out ldc-merge-2.061-2.
Yes, the ldc-merge-2.061-2 is the right one. You might still get linker errors because of undefined math functions. (You could also try the pull request by kinke which implements even more std.math functionality.) A "hello world" application should work. Kai
Jan 25 2013
next sibling parent reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 18:37:09 UTC, Kai Nacke wrote:
 On 25.01.2013 19:31, Sebastian Graf wrote:
 On Friday, 25 January 2013 at 18:25:37 UTC, Kai Nacke wrote:

 The workaround works like a charm... But I had to checkout
 ldc-merge-2.061 to get the libraries to work. That caused me 
 minor
 headaches, but now I'm aware of what are the responsiblities 
 (such as
 x64 support) of which repository...
 I can now INSTALL it, building a hello world app fails however 
 due to
 linker errors in std.math, probably because I forgot to patch. 
 I realize
 now that I should have checked out ldc-merge-2.061-2.
Yes, the ldc-merge-2.061-2 is the right one. You might still get linker errors because of undefined math functions. (You could also try the pull request by kinke which implements even more std.math functionality.) A "hello world" application should work. Kai
I have yet to checkout that commit, but my specific linker error is regarding yl2x, which is not in ldc.intrinsics either. Without it, my hello world won't link... Any suggestions besides a clean build?
Jan 25 2013
parent reply Kai Nacke <kai redstar.de> writes:
On 25.01.2013 20:00, Sebastian Graf wrote:
 On Friday, 25 January 2013 at 18:37:09 UTC, Kai Nacke wrote:
 On 25.01.2013 19:31, Sebastian Graf wrote:
 On Friday, 25 January 2013 at 18:25:37 UTC, Kai Nacke wrote:

 The workaround works like a charm... But I had to checkout
 ldc-merge-2.061 to get the libraries to work. That caused me minor
 headaches, but now I'm aware of what are the responsiblities (such as
 x64 support) of which repository...
 I can now INSTALL it, building a hello world app fails however due to
 linker errors in std.math, probably because I forgot to patch. I realize
 now that I should have checked out ldc-merge-2.061-2.
Yes, the ldc-merge-2.061-2 is the right one. You might still get linker errors because of undefined math functions. (You could also try the pull request by kinke which implements even more std.math functionality.) A "hello world" application should work. Kai
I have yet to checkout that commit, but my specific linker error is regarding yl2x, which is not in ldc.intrinsics either. Without it, my hello world won't link... Any suggestions besides a clean build?
Try to add an empty function "real yl2x(real x, real y)" to longdouble.d Kai
Jan 25 2013
parent "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 19:23:34 UTC, Kai Nacke wrote:
 On 25.01.2013 20:00, Sebastian Graf wrote:
 On Friday, 25 January 2013 at 18:37:09 UTC, Kai Nacke wrote:

 I have yet to checkout that commit, but my specific linker 
 error is
 regarding yl2x, which is not in ldc.intrinsics either. Without 
 it, my
 hello world won't link... Any suggestions besides a clean 
 build?
Try to add an empty function "real yl2x(real x, real y)" to longdouble.d Kai
Adding to longdouble.d was not sufficient because of namespace clash. I had to fix the declaration in phobos' math.d, line 4636 to return 0 for my configuration. Ugly. At least I get my hello world now.
Jan 25 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 25 January 2013 at 18:37:09 UTC, Kai Nacke wrote:
 On 25.01.2013 19:31, Sebastian Graf wrote:
 I realize
 now that I should have checked out ldc-merge-2.061-2.
Yes, the ldc-merge-2.061-2 is the right one.
Feel free to delete the ldc-merge-2.061 one if you no longer need it - I just didn't want to remove your work (even if you'd have a local copy still) without prior discussion, and I can't really spare any time to clean up the merge situation right now. David
Jan 25 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Saturday, 26 January 2013 at 01:45:42 UTC, David Nadlinger 
wrote:
 Feel free to delete the ldc-merge-2.061 one if you no longer 
 need it - I just didn't want to remove your work (even if you'd 
 have a local copy still) without prior discussion, and I can't 
 really spare any time to clean up the merge situation right now.

 David
I killed the branch. I now use the merge-2.061-2 branch and try to kill the bugs... Kai
Jan 26 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 26 January 2013 at 15:50:31 UTC, Kai Nacke wrote:
 I killed the branch. I now use the merge-2.061-2 branch and try 
 to kill the bugs...
Great, thanks! David
Jan 26 2013
prev sibling parent reply "kinke" <noone hotmail.com> writes:
On Friday, 25 January 2013 at 13:55:59 UTC, Sebastian Graf wrote:
 Done. Yet somehow I still can't get it to link druntime. Both 
 in release and debug mode I get 
 http://msdn.microsoft.com/en-us/library/t0cs92zx(v=vs.110).aspx 
 , because /O2 is combined with /RTC1, although the make file 
 defs don't mix anything up. For the exact cl arguments see 
 http://pastie.org/5856844.
I got the same error and got rid of it by editing the VS project files generated by cmake. The debug configurations of druntime, druntime-debug, phobos and phobos-debug use the /RTC1 switch (set in XML by something like <RuntimeChecks>EnableFastChecks</RuntimeChecks>). After removing these lines, the build works. It's strange though, because the debug configs disable any optimization (/Od), so the /O2 must be set somewhere else. Plus I'd expect the release configs to be built, not the debug ones...
Jan 25 2013
parent reply "Sebastian Graf" <SebastianGraf t-online.de> writes:
On Friday, 25 January 2013 at 23:19:31 UTC, kinke wrote:
 On Friday, 25 January 2013 at 13:55:59 UTC, Sebastian Graf 
 wrote:
 Done. Yet somehow I still can't get it to link druntime. Both 
 in release and debug mode I get 
 http://msdn.microsoft.com/en-us/library/t0cs92zx(v=vs.110).aspx 
 , because /O2 is combined with /RTC1, although the make file 
 defs don't mix anything up. For the exact cl arguments see 
 http://pastie.org/5856844.
I got the same error and got rid of it by editing the VS project files generated by cmake. The debug configurations of druntime, druntime-debug, phobos and phobos-debug use the /RTC1 switch (set in XML by something like <RuntimeChecks>EnableFastChecks</RuntimeChecks>). After removing these lines, the build works. It's strange though, because the debug configs disable any optimization (/Od), so the /O2 must be set somewhere else. Plus I'd expect the release configs to be built, not the debug ones...
I did exactly the same before I got the tip on where to edit the makefile. Kinda nasty to remember to apply all those patches again and again...
Jan 25 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 26 January 2013 at 00:55:53 UTC, Sebastian Graf 
wrote:
 I got the same error and got rid of it by editing the VS 
 project files generated by cmake. The debug configurations of 
 druntime, druntime-debug, phobos and phobos-debug use the 
 /RTC1 switch (set in XML by something like 
 <RuntimeChecks>EnableFastChecks</RuntimeChecks>). After 
 removing these lines, the build works. It's strange though, 
 because the debug configs disable any optimization (/Od), so 
 the /O2 must be set somewhere else. Plus I'd expect the 
 release configs to be built, not the debug ones...
I did exactly the same before I got the tip on where to edit the makefile. Kinda nasty to remember to apply all those patches again and again...
Try putting https://github.com/ldc-developers/ldc/blob/master/runtime/CMakeLists.txt#L319 in an "if(NOT MSVC)" block. If it does the trick, please submit it as a pull request (can't test on Windows/MSVC right now). Not building the C parts of the debug runtime in release mode will only decrease performance of debug builds of code that uses e.g. the built-in zlib copy (std.zlib, std.zip). David
Jan 25 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Saturday, 26 January 2013 at 01:50:14 UTC, David Nadlinger
wrote:
 Try putting 
 https://github.com/ldc-developers/ldc/blob/master/runtime/CMakeLists.txt#L319 
 in an "if(NOT MSVC)" block. If it does the trick, please submit 
 it as a pull request (can't test on Windows/MSVC right now).

 Not building the C parts of the debug runtime in release mode 
 will only decrease performance of debug builds of code that 
 uses e.g. the built-in zlib copy (std.zlib, std.zip).

 David
It works and I committed this on master. Coming on merge-2.061-2 branch soon. Kai
Jan 26 2013
prev sibling parent Kai Nacke <kai redstar.de> writes:
Hi Sebastian!

On 25.01.2013 13:21, Sebastian Graf wrote:

 Yeah, so here we go, 15 minutes after posting... The compiler refused to
 parse an fp literal (1.0f), because ld_setll(longdouble*, __int64)
 failed. I don't have that much experience with assembler, but loading
 from [rsp] instead of [esp] in the second line of the definition in
 ldfpu.asm resolved the error for me. I hope this is nothing forbidden to
 do.
The file is part of DMD and used in the MSVC build. Maybe you can try to build DMD with Visual Studio? I would expect that DMD crashes, too. Nevertheless the mix of rsp and esp looks strange and is doomed to fail if the stack address gets larger then 32bit. (That might be a difference between Win 7 and Win 8. I never saw this problem on Win 7.) I'll try your pull request... Kai
Jan 25 2013