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