On Tuesday, 24 September 2013 at 14:48:44 UTC, Iain Buclaw wrote:
On 24 September 2013 15:32, eles <e...@eles.com> wrote:
On Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau
wrote:
Am Tue, 24 Sep 2013 16:02:11 +0200
schrieb "eles" <e...@eles.com>:
Hi,
After compiling/installing the HEAD version of gdc in
/opt/gdc4.9, I
have:
[...]
Those files should be in
/opt/gdc-4.9/include/d/4.9.0/x86_64-unknown-linux-gnu/
Indeed, but only the .di files, nothing about the .d
$ls /opt/gdc-4.9/include/d/4.9.0/x86_64-unknown-linux-gnu/core/
atomic.di cpuid.di exception.di memory.di simd.di
sync time.di
bitop.di demangle.di math.di runtime.di stdc sys
vararg.di
$find . -name 'atomic.d*'
./include/d/4.9.0/x86_64-unknown-linux-gnu/32/core/atomic.di
./include/d/4.9.0/x86_64-unknown-linux-gnu/core/atomic.di
which is OK, as the .d should not be required, but still it is
an asymmetry
wrt phobos.
IIRC, the idea behind was being that compiler generated
interface
files produced would emit only relevant declarations for the
target
(ie: version(X86) { ... } else version (X86_64) { ... } would
be
condensed down to just one or the other). So far this has not
happened - but then again, not much has been done in the way of
cleaning up what gets spewed out of compiler generated
interface files
either...
Hi, sorry for the necro, but this discussion seemed to be somehow
relevant to the problem I'm currently having. I have built GDC
for ARM (on a Raspberry Pi) and I wanted to build dub [1]. This
build fails with the following error:
/usr/local/stow/gdc-4.8.1/include/d/4.8.1/arm-linux-gnueabihf/core/time.di:224:
Error: this cannot be interpreted at compile time, because it has
no available source code
/usr/local/stow/gdc-4.8.1/include/d/4.8.1/std/net/curl.d:195:
called from here: dur(2L)
Is there any way to emit the plain .d files when building GDC, or
some other workaround...?
Actually, as I was typing this, it seems there is a workaround
[2]. Still, there must be a nicer way? I must admit I don't get
the whole .di thing.
Cheers,
Stefan
[1]
http://forum.dlang.org/thread/mxeisicsxpxhijsuh...@forum.dlang.org
[2]
http://forum.dlang.org/post/dpzvxpncqabzxebgd...@forum.dlang.org
