Hi,

 After compiling/installing the HEAD version of gdc in /opt/gdc4.9, I have:

$ls /opt/gdc-4.9/include/d/4.9.0/
core  crc32.d  etc  gcc  object.di  std  x86_64-unknown-linux-gnu

$ls /opt/gdc-4.9/include/d/4.9.0/std/
algorithm.d    csv.d         mathspecial.d  signals.d       uni.d
array.d        datetime.d    md5.d          socket.d        uri.d
ascii.d        demangle.d    metastrings.d  socketstream.d  utf.d
base64.d       digest        mmfile.d       stdint.d        uuid.d
bigint.d       encoding.d    net            stdiobase.d     variant.d
bitmanip.d     exception.d   numeric.d      stdio.d         windows
c              file.d        outbuffer.d    stream.d        xml.d
compiler.d     format.d      parallelism.d  string.d        zip.d
complex.d      functional.d  path.d         syserror.d      zlib.d
concurrency.d  getopt.d      process.d      system.d
container.d    internal      random.d       traits.d
conv.d         json.d        range.d        typecons.d
cstream.d      math.d        regex.d        typetuple.d

(shows that files .d of phobos/std are installed).

OTOH, among files that should be in druntime, only object.di (see above) and thread.di seem to be installed, and no .d files:

$ls /opt/gdc-4.9/include/d/4.9.0/core/
thread.di

The DMD installation seems to deploy files where expected:

-- for druntime:

$ls /usr/include/dmd/druntime/import/core/
atomic.d  cpuid.d     exception.d  memory.d   simd.d  sync  thread.di  vararg.d
bitop.d   demangle.d  math.d       runtime.d  stdc    sys   time.d

-- for phobos:
$ls /usr/include/dmd/phobos/std/
algorithm.d    csv.d         mathspecial.d  signals.d       uni.d
array.d        datetime.d    md5.d          socket.d        uri.d
ascii.d        demangle.d    metastrings.d  socketstream.d  utf.d
base64.d       digest        mmfile.d       stdint.d        uuid.d
bigint.d       encoding.d    net            stdiobase.d     variant.d
bitmanip.d     exception.d   numeric.d      stdio.d         windows
c              file.d        outbuffer.d    stream.d        xml.d
compiler.d     format.d      parallelism.d  string.d        zip.d
complex.d      functional.d  path.d         syserror.d      zlib.d
concurrency.d  getopt.d      process.d      system.d
container.d    internal      random.d       traits.d
conv.d         json.d        range.d        typecons.d
cstream.d      math.d        regex.d        typetuple.d

Am Tue, 24 Sep 2013 16:02:11 +0200
schrieb "eles" <eles@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/

On Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau wrote:
> Am Tue, 24 Sep 2013 16:02:11 +0200
> schrieb "eles" <eles@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.

On 24 September 2013 15:32, eles <eles@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" <eles@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...

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 24 September 2013 at 14:48:44 UTC, Iain Buclaw wrote:
> On 24 September 2013 15:32, eles <eles@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" <eles@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/mxeisicsxpxhijsuhqmp@forum.dlang.org
[2] http://forum.dlang.org/post/dpzvxpncqabzxebgdmuq@forum.dlang.org

On 16 October 2013 20:26, Stefan Frijters <sfrijters@gmail.com> wrote:
> On Tuesday, 24 September 2013 at 14:48:44 UTC, Iain Buclaw wrote:
>>
>> On 24 September 2013 15:32, eles <eles@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" <eles@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.
>

On Ubuntu, there is no workaround other than patching gcc proper with the Ubuntu patches for multiarch.

You are required to set:
CPATH=/usr/include/<arch>
LIBRARY_PATH=/usr/lib/<arch>

So that a vanilla gcc is able to find headers and libraries to compile and link programs


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

If anyone wants to patch gdc to use include paths more similar to usual dmd style, my Arch Linux packaging script can serve as a simple example : https://github.com/Dicebot/Arch-PKGBUILDs/tree/master/gdc (PKGBUILD file is just a special bash script)

On Oct 16, 2013 11:55 PM, "Dicebot" <public@dicebot.lv> wrote:
>
> If anyone wants to patch gdc to use include paths more similar to usual
dmd style, my Arch Linux packaging script can serve as a simple example : https://github.com/Dicebot/Arch-PKGBUILDs/tree/master/gdc (PKGBUILD file is just a special bash script)

Wait, dmd uses /dlang/ now for headers? What a strange compiler... :o)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 16 October 2013 at 23:09:04 UTC, Iain Buclaw wrote:
> Wait, dmd uses /dlang/ now for headers? What a strange compiler... :o)

More like "What a strange packager" ;) I place all stuff under /usr/include/dlang/<compiler name>, helps to experiment with all 3 at once. Of course changing paths in that script is trivial, it is just an example.

On 17 October 2013 00:52, Dicebot <public@dicebot.lv> wrote:
> On Wednesday, 16 October 2013 at 23:09:04 UTC, Iain Buclaw wrote:
>>
>> Wait, dmd uses /dlang/ now for headers? What a strange compiler... :o)
>
>
> More like "What a strange packager" ;) I place all stuff under /usr/include/dlang/<compiler name>, helps to experiment with all 3 at once. Of course changing paths in that script is trivial, it is just an example.

You mean, helps to experiment without needing to remember where each puts their headers?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';