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
parent reply "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
parent reply 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
parent reply "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
next sibling parent reply 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
next sibling parent reply "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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Oct 16 2013
parent reply "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
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 parent reply 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
next sibling parent reply 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
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 reply 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
parent reply "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
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 parent reply "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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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


suite still passed without core.time being CTFEable.


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';



 Oct 17 2013



  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 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  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  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  parent reply 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



  parent reply "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



  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  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