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

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.

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

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.

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

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

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

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

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.

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