www.digitalmars.com         C & C++   DMDScript  

D.gnu - gdc on linux does not install druntime's .d files?

reply "eles" <eles eles.com> writes:
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
Sep 24 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
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/
Sep 24 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 00:34, Iain Buclaw wrote:
 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches? I thought recent GCC supported multiarch out of the box? See: http://forum.dlang.org/post/koa0rg$1m4o$1 digitalmars.com
Oct 16 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 08:24, Iain Buclaw wrote:
 You could try compiling with --enable-multiarch.  But I haven't done so yet. :)

s/compiling/configuring/

Just rebuilding with 4.8.2 in any case, so I'll try that. Though I have no alternative-architecture devices to test with. :-P
Oct 17 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 09:03, Joseph Rushton Wakeling wrote:
 On 17/10/13 08:24, Iain Buclaw wrote:
 You could try compiling with --enable-multiarch.  But I haven't done so yet. :)

s/compiling/configuring/

Just rebuilding with 4.8.2 in any case, so I'll try that. Though I have no alternative-architecture devices to test with. :-P

While we're talking about configure options -- is --disable-multilib still needed?
Oct 17 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 08:24, Iain Buclaw wrote:
 On 17 October 2013 07:17, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On 17/10/13 00:34, Iain Buclaw wrote:
 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches? I thought recent GCC supported multiarch out of the box? See: http://forum.dlang.org/post/koa0rg$1m4o$1 digitalmars.com

You could try compiling with --enable-multiarch. But I haven't done so yet. :)

Well, it compiles fine and seems to run OK. I have nothing to test it with in terms of building stuff for other architectures ...
Oct 17 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 10:37, Stefan Frijters wrote:
 I'm going to reconfigure with --enable-multiarch and rebuild on my RPi. With
 some luck it will have compiled before I go to bed tonight. It *is* awfully
slow
 for this kind of thing :-D

Let me know how you get on. I really must get an RPi of my own -- last time I had my hands on one, no D compiler was at a point where it'd run on or produce binaries for the Pi.
Oct 17 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/10/13 11:09, Johannes Pfau wrote:
 Wait - this is a different problem. It's not a path problem,
 it's really a .di/.d problem.

 DMD seems to ship .d include files for druntime now, they're no longer
 shipping the .di files. The archlinux packages even do this for gdc.
 Some stuff now depends on this, as having the source code available
 allows more stuff to work in ctfe.

 We have to fix this in our libdruntime makefile, we shouldn't
 generate the .di files anymore. Instead we should directly install
 the .d files.

I'm having a similar problem trying to build dub. If you download the dub source from GitHub and try and build using GDC, you get this: $ DC=gdmd ./build.sh Generating version file... Running gdmd... /opt/gdc/include/d/4.8.2/x86_64-unknown-linux-gnu/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /opt/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)
Oct 17 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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.
Sep 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Sep 24 2013
prev sibling next sibling parent "Stefan Frijters" <sfrijters gmail.com> writes:
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
Oct 16 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Oct 16 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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)
Oct 16 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b33d374fddd1704e8e3c807
Content-Type: text/plain; charset=ISO-8859-1

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

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'; --047d7b33d374fddd1704e8e3c807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Oct 16, 2013 11:55 PM, &quot;Dicebot&quot; &lt;<a href=3D"mailto:public = dicebot.lv">public dicebot.lv</a>&gt; wrote:<br> &gt;<br> &gt; If anyone wants to patch gdc to use include paths more similar to usua= l dmd style, my Arch Linux packaging script can serve as a simple example := <a href=3D"https://github.com/Dicebot/Arch-PKGBUILDs/tree/master/gdc">http= s://github.com/Dicebot/Arch-PKGBUILDs/tree/master/gdc</a> (PKGBUILD file is= just a special bash script)</p> <p>Wait, dmd uses /dlang/ now for headers? What a strange compiler... :o)</= p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --047d7b33d374fddd1704e8e3c807--
Oct 16 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Oct 16 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Oct 16 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 17 October 2013 07:17, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 17/10/13 00:34, Iain Buclaw wrote:
 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches? I thought recent GCC supported multiarch out of the box? See: http://forum.dlang.org/post/koa0rg$1m4o$1 digitalmars.com

You could try compiling with --enable-multiarch. But I haven't done so yet. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 16 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 17 October 2013 07:24, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 17 October 2013 07:17, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On 17/10/13 00:34, Iain Buclaw wrote:
 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches? I thought recent GCC supported multiarch out of the box? See: http://forum.dlang.org/post/koa0rg$1m4o$1 digitalmars.com

You could try compiling with --enable-multiarch. But I haven't done so yet. :)

s/compiling/configuring/ -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 16 2013
prev sibling next sibling parent "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 17 October 2013 at 08:28:03 UTC, Joseph Rushton 
Wakeling wrote:
 On 17/10/13 08:24, Iain Buclaw wrote:
 On 17 October 2013 07:17, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On 17/10/13 00:34, Iain Buclaw wrote:
 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches? I thought recent GCC supported multiarch out of the box? See: http://forum.dlang.org/post/koa0rg$1m4o$1 digitalmars.com

You could try compiling with --enable-multiarch. But I haven't done so yet. :)

Well, it compiles fine and seems to run OK. I have nothing to test it with in terms of building stuff for other architectures ...

I'm going to reconfigure with --enable-multiarch and rebuild on my RPi. With some luck it will have compiled before I go to bed tonight. It *is* awfully slow for this kind of thing :-D
Oct 17 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 16 Oct 2013 23:34:11 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 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.

Wait - this is a different problem. It's not a path problem, it's really a .di/.d problem. DMD seems to ship .d include files for druntime now, they're no longer shipping the .di files. The archlinux packages even do this for gdc. Some stuff now depends on this, as having the source code available allows more stuff to work in ctfe. We have to fix this in our libdruntime makefile, we shouldn't generate the .di files anymore. Instead we should directly install the .d files.
Oct 17 2013
prev sibling next sibling parent "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 17 October 2013 at 10:58:43 UTC, Joseph Rushton 
Wakeling wrote:
 On 17/10/13 11:09, Johannes Pfau wrote:
 Wait - this is a different problem. It's not a path problem,
 it's really a .di/.d problem.

 DMD seems to ship .d include files for druntime now, they're 
 no longer
 shipping the .di files. The archlinux packages even do this 
 for gdc.
 Some stuff now depends on this, as having the source code 
 available
 allows more stuff to work in ctfe.

 We have to fix this in our libdruntime makefile, we shouldn't
 generate the .di files anymore. Instead we should directly 
 install
 the .d files.

I'm having a similar problem trying to build dub. If you download the dub source from GitHub and try and build using GDC, you get this: $ DC=gdmd ./build.sh Generating version file... Running gdmd... /opt/gdc/include/d/4.8.2/x86_64-unknown-linux-gnu/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /opt/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)

Yeah, this is the same error that made me necro this thread. Johannes: Is the libdruntime Makefile change going to be tricky, do you think? Or will stripping the -fintfc flags do?
Oct 17 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 17 October 2013 10:09, Johannes Pfau <nospam example.com> wrote:
 Am Wed, 16 Oct 2013 23:34:11 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 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.

Wait - this is a different problem. It's not a path problem, it's really a .di/.d problem. DMD seems to ship .d include files for druntime now, they're no longer shipping the .di files. The archlinux packages even do this for gdc. Some stuff now depends on this, as having the source code available allows more stuff to work in ctfe. We have to fix this in our libdruntime makefile, we shouldn't generate the .di files anymore. Instead we should directly install the .d files.

1. gdc looks for both .d and .di files in the include paths, so that is not the problem... 2. The .di file generation should still be kept around to act as a sanity check to make sure that all is useful for the target platform/architecture. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 17 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 October 2013 at 16:31:21 UTC, Iain Buclaw wrote:
 1. gdc looks for both .d and .di files in the include paths, so 
 that
 is not the problem...

Isn't this done in front-end? If .di file is found, *.d won't be searched.
Oct 17 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 17 October 2013 at 09:10:43 UTC, Johannes Pfau wrote:
 DMD seems to ship .d include files for druntime now, they're no 
 longer
 shipping the .di files. The archlinux packages even do this for 
 gdc.
 Some stuff now depends on this, as having the source code 
 available
 allows more stuff to work in ctfe.

And so does LDC. Actually, I'd be somewhat surprised if the Phobos test suite still passed without core.time being CTFEable. David
Oct 17 2013
prev sibling next sibling parent "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 17 October 2013 at 16:35:48 UTC, Dicebot wrote:
 On Thursday, 17 October 2013 at 16:31:21 UTC, Iain Buclaw wrote:
 1. gdc looks for both .d and .di files in the include paths, 
 so that
 is not the problem...

Isn't this done in front-end? If .di file is found, *.d won't be searched.

DMD does it this way, according to http://dlang.org/dmd-linux.html#interface_files "D interface files can be created by the compiler from a D source file by using the -H switch to the compiler. D interface files have the .di file extension. When the compiler resolves an import declaration, it first looks for a .di D interface file, then it looks for a D source file." That way the compilation would still get stuck, wouldn't it?
Oct 17 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a1133a002f119d404e8f72514
Content-Type: text/plain; charset=ISO-8859-1

On Oct 17, 2013 6:20 PM, "David Nadlinger" <code klickverbot.at> wrote:
 On Thursday, 17 October 2013 at 09:10:43 UTC, Johannes Pfau wrote:
 DMD seems to ship .d include files for druntime now, they're no longer
 shipping the .di files. The archlinux packages even do this for gdc.
 Some stuff now depends on this, as having the source code available
 allows more stuff to work in ctfe.

And so does LDC. Actually, I'd be somewhat surprised if the Phobos test


I'll have to re-check this. At the last time I looked, the interface file generation part of the front end did not omit the bodies of functions defined in modules. I may perhaps be getting confused with version statements though. ;) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a1133a002f119d404e8f72514 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Oct 17, 2013 6:20 PM, &quot;David Nadlinger&quot; &lt;<a href=3D"mailto:= code klickverbot.at">code klickverbot.at</a>&gt; wrote:<br> &gt;<br> &gt; On Thursday, 17 October 2013 at 09:10:43 UTC, Johannes Pfau wrote:<br> &gt;&gt;<br> &gt;&gt; DMD seems to ship .d include files for druntime now, they&#39;re n= o longer<br> &gt;&gt; shipping the .di files. The archlinux packages even do this for gd= c.<br> &gt;&gt; Some stuff now depends on this, as having the source code availabl= e<br> &gt;&gt; allows more stuff to work in ctfe.<br> &gt;<br> &gt;<br> &gt; And so does LDC. Actually, I&#39;d be somewhat surprised if the Phobos= test suite still passed without core.time being CTFEable.<br> &gt;</p> <p>I&#39;ll have to re-check this. At the last time I looked, the interface= file generation part of the front end did not omit the bodies of functions= defined in modules.=A0=A0 I may perhaps be getting confused with version s= tatements though. ;)<br> </p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --001a1133a002f119d404e8f72514--
Oct 17 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 17 October 2013 at 22:15:07 UTC, Iain Buclaw wrote:
 I'll have to re-check this. At the last time I looked, the 
 interface file
 generation part of the front end did not omit the bodies of 
 functions
 defined in modules.

It does now (unless -inline is given for DMD, or -Hkeep-all-bodies for LDC). David
Oct 17 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 24 Sep 2013 16:02:11 +0200
schrieb "eles" <eles eles.com>:

[...]

Damn, I hate shell scripts / Makefiles:
https://github.com/jpf91/GDC/commit/d9a6e38dd140b9a98ce694b2073714983c7af6a3

BTW: We could make this more failsafe by using "find" to search the
source directory recursively. This way we wouldn't have the list all
subfolders in the Makefile. But that only works if we copy all files to
the same destination, we couldn't copy some files to
${include}/${target_triplet} as we do now.
Dec 01 2013