January 25, 2013
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?
January 25, 2013
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
January 25, 2013
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.
January 25, 2013
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...
January 26, 2013
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...
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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

Next ›   Last »
1 2