D.gnu - gdc on linux does not install druntime's .d files?
- eles (49/49) Sep 24 2013 Hi,
- Johannes Pfau (4/9) Sep 24 2013 Those files should be in
- eles (13/22) Sep 24 2013 Indeed, but only the .di files, nothing about the .d
- Iain Buclaw (11/34) Sep 24 2013 IIRC, the idea behind was being that compiler generated interface
- Stefan Frijters (21/66) Oct 16 2013 Hi, sorry for the necro, but this discussion seemed to be somehow
- Iain Buclaw (12/71) Oct 16 2013 On Ubuntu, there is no workaround other than patching gcc proper with
- Dicebot (5/5) Oct 16 2013 If anyone wants to patch gdc to use include paths more similar to
- Iain Buclaw (9/10) Oct 16 2013 dmd style, my Arch Linux packaging script can serve as a simple example ...
- Dicebot (5/7) Oct 16 2013 More like "What a strange packager" ;) I place all stuff under
- Iain Buclaw (6/12) Oct 16 2013 You mean, helps to experiment without needing to remember where each
- Johannes Pfau (11/34) Oct 17 2013 Wait - this is a different problem. It's not a path problem,
- Joseph Rushton Wakeling (10/19) Oct 17 2013 I'm having a similar problem trying to build dub.
- Stefan Frijters (5/32) Oct 17 2013 Yeah, this is the same error that made me necro this thread.
- Iain Buclaw (9/43) Oct 17 2013 1. gdc looks for both .d and .di files in the include paths, so that
- Dicebot (3/6) Oct 17 2013 Isn't this done in front-end? If .di file is found, *.d won't be
- Stefan Frijters (9/15) Oct 17 2013 DMD does it this way, according to
- David Nadlinger (4/11) Oct 17 2013 And so does LDC. Actually, I'd be somewhat surprised if the
- Iain Buclaw (10/17) Oct 17 2013 suite still passed without core.time being CTFEable.
- David Nadlinger (4/9) Oct 17 2013 It does now (unless -inline is given for DMD, or
- Joseph Rushton Wakeling (5/12) Oct 16 2013 So, still worth using the deb source package instead of vanilla GCC, and...
- Iain Buclaw (6/21) Oct 16 2013 You could try compiling with --enable-multiarch. But I haven't done so ...
- Iain Buclaw (5/27) Oct 16 2013 s/compiling/configuring/
- Joseph Rushton Wakeling (3/6) Oct 17 2013 Just rebuilding with 4.8.2 in any case, so I'll try that. Though I have...
- Joseph Rushton Wakeling (2/9) Oct 17 2013 While we're talking about configure options -- is --disable-multilib sti...
- Joseph Rushton Wakeling (3/25) Oct 17 2013 Well, it compiles fine and seems to run OK. I have nothing to test it w...
- Stefan Frijters (5/36) Oct 17 2013 I'm going to reconfigure with --enable-multiarch and rebuild on
- Joseph Rushton Wakeling (4/7) Oct 17 2013 Let me know how you get on. I really must get an RPi of my own -- last ...
- Johannes Pfau (10/10) Dec 01 2013 Am Tue, 24 Sep 2013 16:02:11 +0200
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
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
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>: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.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
On 24 September 2013 15:32, eles <eles eles.com> wrote:On Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau wrote: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';Am Tue, 24 Sep 2013 16:02:11 +0200 schrieb "eles" <eles eles.com>: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.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
On Tuesday, 24 September 2013 at 14:48:44 UTC, Iain Buclaw wrote:On 24 September 2013 15:32, eles <eles eles.com> wrote: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.orgOn Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau wrote: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...Am Tue, 24 Sep 2013 16:02:11 +0200 schrieb "eles" <eles eles.com>: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.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/
Oct 16 2013
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 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';On 24 September 2013 15:32, eles <eles eles.com> wrote: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 Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau wrote: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...Am Tue, 24 Sep 2013 16:02:11 +0200 schrieb "eles" <eles eles.com>: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.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/
Oct 16 2013
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
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 usualdmd 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';
Oct 16 2013
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
On 17 October 2013 00:52, Dicebot <public dicebot.lv> wrote:On Wednesday, 16 October 2013 at 23:09:04 UTC, Iain Buclaw wrote:You mean, helps to experiment without needing to remember where each puts their headers? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
Am Wed, 16 Oct 2013 23:34:11 +0100 schrieb Iain Buclaw <ibuclaw ubuntu.com>: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.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.
Oct 17 2013
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
On Thursday, 17 October 2013 at 10:58:43 UTC, Joseph Rushton Wakeling wrote:On 17/10/13 11:09, Johannes Pfau wrote: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?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
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>: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';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.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.
Oct 17 2013
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
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: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?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
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
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:suite still passed without core.time being CTFEable.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 testI'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';
Oct 17 2013
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
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 programsSo, 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
On 17 October 2013 07:17, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:On 17/10/13 00:34, Iain Buclaw wrote:You could try compiling with --enable-multiarch. But I haven't done so yet. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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 programsSo, 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
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:s/compiling/configuring/ -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On 17/10/13 00:34, Iain Buclaw wrote:You could try compiling with --enable-multiarch. But I haven't done so yet. :)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 programsSo, 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
On 17/10/13 08:24, Iain Buclaw wrote:Just rebuilding with 4.8.2 in any case, so I'll try that. Though I have no alternative-architecture devices to test with. :-PYou could try compiling with --enable-multiarch. But I haven't done so yet. :)s/compiling/configuring/
Oct 17 2013
On 17/10/13 09:03, Joseph Rushton Wakeling wrote:On 17/10/13 08:24, Iain Buclaw wrote:While we're talking about configure options -- is --disable-multilib still needed?Just rebuilding with 4.8.2 in any case, so I'll try that. Though I have no alternative-architecture devices to test with. :-PYou could try compiling with --enable-multiarch. But I haven't done so yet. :)s/compiling/configuring/
Oct 17 2013
On 17/10/13 08:24, Iain Buclaw wrote:On 17 October 2013 07:17, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:Well, it compiles fine and seems to run OK. I have nothing to test it with in terms of building stuff for other architectures ...On 17/10/13 00:34, Iain Buclaw wrote:You could try compiling with --enable-multiarch. But I haven't done so yet. :)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 programsSo, 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 17 2013
On Thursday, 17 October 2013 at 08:28:03 UTC, Joseph Rushton Wakeling wrote:On 17/10/13 08:24, Iain Buclaw 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 :-DOn 17 October 2013 07:17, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:Well, it compiles fine and seems to run OK. I have nothing to test it with in terms of building stuff for other architectures ...On 17/10/13 00:34, Iain Buclaw wrote:You could try compiling with --enable-multiarch. But I haven't done so yet. :)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 programsSo, 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 17 2013
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 :-DLet 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
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