On Friday, 24 October 2014 at 16:28:13 UTC, Kai Nacke wrote:
> I do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch.

That's not the issue, it's something along the lines of -O3 -release -disable-boundscheck by default.

> Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz@forum.dlang.org). Using -singleobj with multiple objects might help, too.

The issues is most probably not related to optimization at all. I obviously can't say any definitive without more context/code, but it looks like we might emit a manifest constant once and unconditionally instead of on every use (there is/was even an ancient fixme note about this in the code at some point).

CTFE itself seems not to be directly related to the issue. It only happens to produce the initializer we erroneously emit afterwards. And regarding the optimizer, the only thing we could there is to catch that the value is never used/escaped and elide it, but clearly it just shouldn't be there in the first place.

David

On Friday, 24 October 2014 at 21:21:40 UTC, David Nadlinger wrote:
> On Friday, 24 October 2014 at 16:28:13 UTC, Kai Nacke wrote:
>> I do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch.
>
> That's not the issue, it's something along the lines of -O3 -release -disable-boundscheck by default.
>
>> Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz@forum.dlang.org). Using -singleobj with multiple objects might help, too.
>
> The issues is most probably not related to optimization at all. I obviously can't say any definitive without more context/code, but it looks like we might emit a manifest constant once and unconditionally instead of on every use (there is/was even an ancient fixme note about this in the code at some point).
>
> CTFE itself seems not to be directly related to the issue. It only happens to produce the initializer we erroneously emit afterwards. And regarding the optimizer, the only thing we could there is to catch that the value is never used/escaped and elide it, but clearly it just shouldn't be there in the first place.
>
> David

I've reduced the code needed to reproduce the issue:

https://github.com/ldc-developers/ldc/issues/762

Building DCD (d completion daemon) is failing for me. The build
works with DMD though. It was failing with the same error on
0.14.0 too, so it's not something new. I'm on OS X. It might just
be a stupid mistake on my part. Here's my error message:

Undefined symbols for architecture x86_64:
   "__D4core8internal4hash9bytesHashFNaNbNePxvmmZm", referenced
from:
       __D11modulecache10CacheEntry6toHashMxFNbNfZm in
modulecache.o

__D4core8internal4hash16__T6hashOfTxAyaZ6hashOfFNaNbNeKxAyamZm in
modulecache.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)

Hi Andrei,

On 27 Oct 2014, at 2:24, Andrei Amatuni via digitalmars-d-ldc wrote:
> It might just be a stupid mistake on my part. […]
>  "__D4core8internal4hash9bytesHashFNaNbNePxvmmZm" […]

This looks like it might just be a stupid mistake on _our_ part: https://github.com/ldc-developers/ldc/pull/770

Cheers,
David

On Monday, 27 October 2014 at 02:32:35 UTC, David Nadlinger via
digitalmars-d-ldc wrote:
> Hi Andrei,
>
> On 27 Oct 2014, at 2:24, Andrei Amatuni via digitalmars-d-ldc wrote:
>> It might just be a stupid mistake on my part. […]
>> "__D4core8internal4hash9bytesHashFNaNbNePxvmmZm" […]
>
> This looks like it might just be a stupid mistake on _our_ part: https://github.com/ldc-developers/ldc/pull/770
>
> Cheers,
> David

Hey David,

Thanks for the quick response! I was almost sure it was my fault.
Spent some time tinkering with ldflags/library_path but still no
luck. Hopefully this takes care of it.

Andrei

Am Fri, 24 Oct 2014 20:56:27 +0000
schrieb "Anonymus" <a@b.com>:

> The only minor problem is that I can't use the compilation speed of dmd during development because it is unable to link against my gtkd (compiled by an old LDC version) - not sure wether that is related.

And that's why on Gentoo Linux I made it so GtkD is installed once per dmd version, ldc2 version, gdc version and pointer size. So on Gentoo you can unleash the speed of DMD with installed D libraries and also compile your release versions with ldc2 or gdc.

Just remember not to mix object files produced by different compilers or different compiler versions. Some APIs in Phobos changed even from 2.066.0 to 2.066.1.

-- 
Marco

On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:
> Hi everyone!
>
> On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release!
> It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).
>
> This is a really exciting release!
>
<snip>

I have an up-to-date version of Crunchbang running on a Thinkpad R52.  Starting with version 0.13, I get

ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2)
ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2)

when trying to run the binary images.  This keeps me at 0.12.

On 5 Nov 2014, at 17:32, Steve via digitalmars-d-ldc wrote:
> I have an up-to-date version of Crunchbang running on a Thinkpad R52.  Starting with version 0.13, I get
>
> ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2)
> ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2)
>
> when trying to run the binary images.  This keeps me at 0.12.

Seems like your libc is older than the one the binary packages were built against.

Kai has been building the release packages since I handed over maintainership to him, but generally our strategy is to build them on the second-to-last Ubuntu LTS release. Right now, this is 12.04, which over 2.5 years old at this point. Generally, we've found this to be enough for the vast majority of users to be able to just use the binary releases. If you want to use it on an older system, you can always compile it from source yourself.

By the way, thanks to Konstantinos are now Debian packages for LDC. I've no idea how feasible it is to backport them to whatever Crunchbang is using, but it might simplify things.

Regards,
David

On Thursday, 6 November 2014 at 20:29:53 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> On 5 Nov 2014, at 17:32, Steve via digitalmars-d-ldc wrote:
>> I have an up-to-date version of Crunchbang running on a Thinkpad R52.  Starting with version 0.13, I get
>>
>> ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2)
>> ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2)
>>
> Kai has been building the release packages since I handed over maintainership to him, but generally our strategy is to build them on the second-to-last Ubuntu LTS release. Right now, this is 12.04, which over 2.5 years old at this point. Generally, we've found this to be enough for the vast majority of users to be able to just use the binary releases. If you want to use it on an older system, you can always compile it from source yourself.

I am building the binaries on Ubuntu 12.04.5 LTS. The mentioned libstdc++ version is indeed used.
Starting with release 0.1.50, the only difference to a vanilla 12.04 LTS is the backported gcc 4.8.1 which is required to compile LLVM 3.5+

Regards,
Kai