www.digitalmars.com         C & C++   DMDScript  

D.gnu - D on the Raspberry Pi

reply "Henry Robbins Gouk" <henry.gouk gmail.com> writes:
Hi all,

I was wondering if anyone has managed to successfully compile a 
GDC cross compiler to target the Raspberry Pi?

I tried following the instructions found at 
http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I try 
the "ct-ng build" command I get the following output:

[INFO ]  Performing some trivial sanity checks
[INFO ]  Build started 20120613.010123
[INFO ]  Building environment variables
[ERROR]  Static linking impossible on the host system 
'x86_64-build_unknown-linux-gnu'
[00:02] / make: *** [build] Error 1

Should I continue along the path of using crosstools to make a 
cross compiler, and if so; how? Or is there a better way to 
achieve my end goal of having a cross compiler targeting the 
Raspberry Pi?

Thanks in advance for any help :-)
Jun 12 2012
parent reply =?UTF-8?B?IlPDtm5rZQ==?= Ludwig" <sludwig outerproduct.org> writes:
On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
wrote:

 Hi all,

 I was wondering if anyone has managed to successfully compile a 
 GDC cross compiler to target the Raspberry Pi?

 I tried following the instructions found at 
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I 
 try the "ct-ng build" command I get the following output:

 [INFO ]  Performing some trivial sanity checks
 [INFO ]  Build started 20120613.010123
 [INFO ]  Building environment variables
 [ERROR]  Static linking impossible on the host system 
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a 
 cross compiler, and if so; how? Or is there a better way to 
 achieve my end goal of having a cross compiler targeting the 
 Raspberry Pi?

 Thanks in advance for any help :-)


I tried to build it as a cross compiler and on the raspberry
directly - and faild at both. On the raspberry I got a compiler
crash, and the cross compiler build process produced random
errors - it seems to be very fragile in terms of library versions
and such.

...so I would also be very interested in any sucess stories.
Jun 12 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 June 2012 16:57, <sludwig outerproduct.org>" puremagic.com
<"\"S=F6nke".Ludwig"> wrote:

 On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
 wrote:


 Hi all,

 I was wondering if anyone has managed to successfully compile a GDC cros=




s

 compiler to target the Raspberry Pi?

 I tried following the instructions found at
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I try the "c=




t-ng

 build" command I get the following output:

 [INFO ] =A0Performing some trivial sanity checks
 [INFO ] =A0Build started 20120613.010123
 [INFO ] =A0Building environment variables
 [ERROR] =A0Static linking impossible on the host system
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a cross
 compiler, and if so; how? Or is there a better way to achieve my end goa=




l of

 having a cross compiler targeting the Raspberry Pi?

 Thanks in advance for any help :-)



 I tried to build it as a cross compiler and on the raspberry
 directly - and faild at both. On the raspberry I got a compiler
 crash, and the cross compiler build process produced random
 errors - it seems to be very fragile in terms of library versions
 and such.

 ...so I would also be very interested in any sucess stories.


Does it get as far as building libphobos/libdruntime ?

I would be interested in, if possible:

1) Build logs or exact errors of what ICE's / crashes you are getting
from the compiler.
2) A copy of the generated phobos-vers-sym file from the libphobos
build directory.
3) A copy of d-confdefs.h from the gcc/d build directory.


Regards

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jun 12 2012
next sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 12.06.2012 18:09, schrieb Iain Buclaw:

 On 12 June 2012 16:57,<sludwig outerproduct.org>" puremagic.com
 <"\"Sönke".Ludwig">  wrote:

 On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
 wrote:


 Hi all,

 I was wondering if anyone has managed to successfully compile a GDC cross
 compiler to target the Raspberry Pi?

 I tried following the instructions found at
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I try the "ct-ng
 build" command I get the following output:

 [INFO ]  Performing some trivial sanity checks
 [INFO ]  Build started 20120613.010123
 [INFO ]  Building environment variables
 [ERROR]  Static linking impossible on the host system
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a cross
 compiler, and if so; how? Or is there a better way to achieve my end goal of
 having a cross compiler targeting the Raspberry Pi?

 Thanks in advance for any help :-)



 I tried to build it as a cross compiler and on the raspberry
 directly - and faild at both. On the raspberry I got a compiler
 crash, and the cross compiler build process produced random
 errors - it seems to be very fragile in terms of library versions
 and such.

 ...so I would also be very interested in any sucess stories.


 Does it get as far as building libphobos/libdruntime ?

 I would be interested in, if possible:

 1) Build logs or exact errors of what ICE's / crashes you are getting
 from the compiler.
 2) A copy of the generated phobos-vers-sym file from the libphobos
 build directory.
 3) A copy of d-confdefs.h from the gcc/d build directory.


 Regards


It failed already during the gdc build. I'll repeat the process and 
collect the logs (I hope I can do that sometime this weekend).
Jun 12 2012
prev sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
 1) Build logs or exact errors of what ICE's / crashes you are getting
 from the compiler.
 2) A copy of the generated phobos-vers-sym file from the libphobos
 build directory.
 3) A copy of d-confdefs.h from the gcc/d build directory.


I retried now with your version of GDC on github and didn't get the ICE 
but always got some compile errors (I first went from gcc 4.6.1 over 
4.7.0 and 4.7.1 to a snapshot of 4.8 from march and finally to the 
20120617 snapshot). The configure/make output is attached and the 
gcc/d/d-confdefs.h contains:

#define D_CPU_VERSION "ARM"
#define D_OS_VERSION "linux"
#define TARGET_LINUX 1

The error is that the macro "#define CLEAR_INSN_CACHE(REG, END) 
not_used" is used somewhere in the libgcc target. There are two logs 
because there was a weird make crash on the first run - the second build 
proceeded further. I didn't get to the libphobos stuff so there is no 
phobos-vers-sym file.

Regards,
Sönke
Jun 19 2012
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 12 Jun 2012 17:57:39 +0200
schrieb "S=C3=B6nke Ludwig" <sludwig outerproduct.org>:


 On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
 wrote:

 Hi all,

 I was wondering if anyone has managed to successfully compile a=20
 GDC cross compiler to target the Raspberry Pi?

 I tried following the instructions found at=20
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I=20
 try the "ct-ng build" command I get the following output:

 [INFO ]  Performing some trivial sanity checks
 [INFO ]  Build started 20120613.010123
 [INFO ]  Building environment variables
 [ERROR]  Static linking impossible on the host system=20
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a=20
 cross compiler, and if so; how? Or is there a better way to=20
 achieve my end goal of having a cross compiler targeting the=20
 Raspberry Pi?

 Thanks in advance for any help :-)


=20
 I tried to build it as a cross compiler and on the raspberry
 directly - and faild at both. On the raspberry I got a compiler
 crash, and the cross compiler build process produced random
 errors - it seems to be very fragile in terms of library versions
 and such.
=20
 ...so I would also be very interested in any sucess stories.


Sorry, probably a stupid question, but could the build on the PI have
died because of too little ram?

Anyway, building a compiler on the raspberry pi worked for me, although
it took a long time to build. I created a new wiki page with build
instructions:
https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi
Jul 03 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 3 July 2012 18:30, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 12 Jun 2012 17:57:39 +0200
 schrieb "S=F6nke Ludwig" <sludwig outerproduct.org>:


 On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
 wrote:

 Hi all,

 I was wondering if anyone has managed to successfully compile a
 GDC cross compiler to target the Raspberry Pi?

 I tried following the instructions found at
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I
 try the "ct-ng build" command I get the following output:

 [INFO ]  Performing some trivial sanity checks
 [INFO ]  Build started 20120613.010123
 [INFO ]  Building environment variables
 [ERROR]  Static linking impossible on the host system
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a
 cross compiler, and if so; how? Or is there a better way to
 achieve my end goal of having a cross compiler targeting the
 Raspberry Pi?

 Thanks in advance for any help :-)


 I tried to build it as a cross compiler and on the raspberry
 directly - and faild at both. On the raspberry I got a compiler
 crash, and the cross compiler build process produced random
 errors - it seems to be very fragile in terms of library versions
 and such.

 ...so I would also be very interested in any sucess stories.


 Sorry, probably a stupid question, but could the build on the PI have
 died because of too little ram?

 Anyway, building a compiler on the raspberry pi worked for me, although
 it took a long time to build. I created a new wiki page with build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


I have a wiki at http://gdcproject.org/wiki   :-)


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jul 03 2012
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 03.07.2012 19:30, schrieb Johannes Pfau:

 Am Tue, 12 Jun 2012 17:57:39 +0200
 schrieb "Sönke Ludwig" <sludwig outerproduct.org>:


 On Tuesday, 12 June 2012 at 13:06:05 UTC, Henry Robbins Gouk
 wrote:

 Hi all,

 I was wondering if anyone has managed to successfully compile a
 GDC cross compiler to target the Raspberry Pi?

 I tried following the instructions found at
 http://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but when I
 try the "ct-ng build" command I get the following output:

 [INFO ]  Performing some trivial sanity checks
 [INFO ]  Build started 20120613.010123
 [INFO ]  Building environment variables
 [ERROR]  Static linking impossible on the host system
 'x86_64-build_unknown-linux-gnu'
 [00:02] / make: *** [build] Error 1

 Should I continue along the path of using crosstools to make a
 cross compiler, and if so; how? Or is there a better way to
 achieve my end goal of having a cross compiler targeting the
 Raspberry Pi?

 Thanks in advance for any help :-)


 I tried to build it as a cross compiler and on the raspberry
 directly - and faild at both. On the raspberry I got a compiler
 crash, and the cross compiler build process produced random
 errors - it seems to be very fragile in terms of library versions
 and such.

 ...so I would also be very interested in any sucess stories.


 Sorry, probably a stupid question, but could the build on the PI have
 died because of too little ram?

 Anyway, building a compiler on the raspberry pi worked for me, although
 it took a long time to build. I created a new wiki page with build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


Out of memory was the first problem if I remember right, which I fixed 
by enabling swap, but all the following errors were something different. 
Your instructions look a lot like what I've tried last, apart from some 
command switches. I will try again with those.
Jul 07 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
 Anyway, building a compiler on the raspberry pi worked for me, although
 it took a long time to build. I created a new wiki page with build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


I've done some new attempts. After using a different OS image on a 
different SD card, everything worked much better (raspbian "Pisces"). I 
followed your instructions on the wiki page but had to change 
arm-linux-gnueabi to arm-linux-gnueabihf and later removed them 
altogether with the same effect.

However, compilation got stuck at the same place as before. It couldn't 
find <bits/predefs.h> and other architecture specific files. Symlinking 
from /usr/include/arm-linux-gnueabihf/* to gcc/* helped a bit until it 
stopped with the same error as in the build log that I posted before.

I will probably just try the debian image, although a system with 
hardfloat support would be pretty important in the long run. But the 
fact that it doesn't find the /sys/, /bits/ etc. headers sounds like it 
is just some stupid little build problem. But I'm much too unfamiliar 
with the GCC build process to make effective guesses for a solution.
Jul 15 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Sunday, 15 July 2012 at 15:11:03 UTC, Sönke Ludwig wrote:

 Anyway, building a compiler on the raspberry pi worked for me, 
 although
 it took a long time to build. I created a new wiki page with 
 build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


 I've done some new attempts. After using a different OS image 
 on a different SD card, everything worked much better (raspbian 
 "Pisces"). I followed your instructions on the wiki page but 
 had to change arm-linux-gnueabi to arm-linux-gnueabihf and 
 later removed them altogether with the same effect.

 However, compilation got stuck at the same place as before. It 
 couldn't find <bits/predefs.h> and other architecture specific 
 files. Symlinking from /usr/include/arm-linux-gnueabihf/* to 
 gcc/* helped a bit until it stopped with the same error as in 
 the build log that I posted before.

 I will probably just try the debian image, although a system 
 with hardfloat support would be pretty important in the long 
 run. But the fact that it doesn't find the /sys/, /bits/ etc. 
 headers sounds like it is just some stupid little build 
 problem. But I'm much too unfamiliar with the GCC build process 
 to make effective guesses for a solution.


Following the instructions at Johannes Pfau's link above I
managed to get the compiler up and running on the squeeze image
(not counting stupidity on my part which made the compilation
fail more than six hours into the process...). So thanks for
that! However, I am curious if anyone has made any progress
getting it to work on the raspbian image. I will try some things
tomorrow (though I'm a newbie, so I doubt I'll get very far on my
own) but with the 8-hour compilation cycles I would like to avoid
any stupid mistakes if possible. Any experiences or tips would be
helpful!

Regards,

Stefan
Aug 01 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 02 Aug 2012 00:30:35 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 On Sunday, 15 July 2012 at 15:11:03 UTC, S=C3=B6nke Ludwig wrote:

 Anyway, building a compiler on the raspberry pi worked for me,=20
 although
 it took a long time to build. I created a new wiki page with=20
 build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


 I've done some new attempts. After using a different OS image=20
 on a different SD card, everything worked much better (raspbian=20
 "Pisces"). I followed your instructions on the wiki page but=20
 had to change arm-linux-gnueabi to arm-linux-gnueabihf and=20
 later removed them altogether with the same effect.

 However, compilation got stuck at the same place as before. It=20
 couldn't find <bits/predefs.h> and other architecture specific=20
 files. Symlinking from /usr/include/arm-linux-gnueabihf/* to=20
 gcc/* helped a bit until it stopped with the same error as in=20
 the build log that I posted before.

 I will probably just try the debian image, although a system=20
 with hardfloat support would be pretty important in the long=20
 run. But the fact that it doesn't find the /sys/, /bits/ etc.=20
 headers sounds like it is just some stupid little build=20
 problem. But I'm much too unfamiliar with the GCC build process=20
 to make effective guesses for a solution.


=20
 Following the instructions at Johannes Pfau's link above I
 managed to get the compiler up and running on the squeeze image
 (not counting stupidity on my part which made the compilation
 fail more than six hours into the process...). So thanks for
 that! However, I am curious if anyone has made any progress
 getting it to work on the raspbian image. I will try some things
 tomorrow (though I'm a newbie, so I doubt I'll get very far on my
 own) but with the 8-hour compilation cycles I would like to avoid
 any stupid mistakes if possible. Any experiences or tips would be
 helpful!
=20
 Regards,
=20
 Stefan
=20


I haven't tried raspbian yet, but it's always good to make sure all
packages necessary for building gcc are installed (make sure to do
this before calling the gcc configure script!):
-----------
sudo apt-get install build-essential git
sudo apt-get build-dep gcc
-----------
also make sure to enable swap.

Usually the configure flags described on GDC's main page work fine:
-----------
../configure --enable-languages=3Dd --disable-bootstrap \
        --disable-shared --disable-nls --prefix=3D/opt/gdc \
        --with-bugurl=3D"https://bitbucket.org/goshawk/gdc/issues" \
        --enable-checking=3Dyes \
        --disable-libgomp --disable-libmudflap
-----------

but you can also have a look at the flags the system gcc has been
compiled with:
-----------
gcc -v
-----------
Aug 02 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 2 August 2012 at 07:49:14 UTC, Johannes Pfau wrote:

 Am Thu, 02 Aug 2012 00:30:35 +0200
 schrieb "Stefan Frijters" <sfrijters gmail.com>:


 On Sunday, 15 July 2012 at 15:11:03 UTC, Sönke Ludwig wrote:

 Anyway, building a compiler on the raspberry pi worked for 
 me, although
 it took a long time to build. I created a new wiki page 
 with build
 instructions:
 https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi


 I've done some new attempts. After using a different OS 
 image on a different SD card, everything worked much better 
 (raspbian "Pisces"). I followed your instructions on the 
 wiki page but had to change arm-linux-gnueabi to 
 arm-linux-gnueabihf and later removed them altogether with 
 the same effect.

 However, compilation got stuck at the same place as before. 
 It couldn't find <bits/predefs.h> and other architecture 
 specific files. Symlinking from 
 /usr/include/arm-linux-gnueabihf/* to gcc/* helped a bit 
 until it stopped with the same error as in the build log 
 that I posted before.

 I will probably just try the debian image, although a system 
 with hardfloat support would be pretty important in the long 
 run. But the fact that it doesn't find the /sys/, /bits/ 
 etc. headers sounds like it is just some stupid little build 
 problem. But I'm much too unfamiliar with the GCC build 
 process to make effective guesses for a solution.


 
 Following the instructions at Johannes Pfau's link above I
 managed to get the compiler up and running on the squeeze image
 (not counting stupidity on my part which made the compilation
 fail more than six hours into the process...). So thanks for
 that! However, I am curious if anyone has made any progress
 getting it to work on the raspbian image. I will try some 
 things
 tomorrow (though I'm a newbie, so I doubt I'll get very far on 
 my
 own) but with the 8-hour compilation cycles I would like to 
 avoid
 any stupid mistakes if possible. Any experiences or tips would 
 be
 helpful!
 
 Regards,
 
 Stefan
 


 I haven't tried raspbian yet, but it's always good to make sure 
 all
 packages necessary for building gcc are installed (make sure to 
 do
 this before calling the gcc configure script!):
 -----------
 sudo apt-get install build-essential git
 sudo apt-get build-dep gcc
 -----------
 also make sure to enable swap.

 Usually the configure flags described on GDC's main page work 
 fine:
 -----------
 ../configure --enable-languages=d --disable-bootstrap \
         --disable-shared --disable-nls --prefix=/opt/gdc \
         
 --with-bugurl="https://bitbucket.org/goshawk/gdc/issues" \
         --enable-checking=yes \
         --disable-libgomp --disable-libmudflap
 -----------

 but you can also have a look at the flags the system gcc has 
 been
 compiled with:
 -----------
 gcc -v
 -----------


Thank you for the pointers. I just got the results of my first 
attempt (it failed). I'm getting the same error as reported by 
Sönke Ludwig above, and after some googling it seems to be 
related to 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm now 
going to retry with 'env CFLAGS="-g -O2 
-I/usr/include/arm-linux-gnueabihf" 
LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. I 
put in the "-g -O2" because that is something the make mentioned 
being there before. I guess I'll know if it worked in the 
morning...

Cheers,

Stefan
Aug 02 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 02 Aug 2012 20:15:47 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 Thank you for the pointers. I just got the results of my first=20
 attempt (it failed). I'm getting the same error as reported by=20
 S=C3=B6nke Ludwig above, and after some googling it seems to be=20
 related to=20
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D648889 . I'm now=20
 going to retry with 'env CFLAGS=3D"-g -O2=20
 -I/usr/include/arm-linux-gnueabihf"=20
 LDFLAGS=3D"-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. I=20
 put in the "-g -O2" because that is something the make mentioned=20
 being there before. I guess I'll know if it worked in the=20
 morning...
=20
 Cheers,
=20
 Stefan
=20


I didn't know the debian multiarch changes also affect non-multiarch
installations. Adding -I/usr/include/arm-linux-gnueabihf to CFLAGS
probably works (your link also suggests adding
-B/usr/include/arm-linux-gnueabihf though). Adding -O2 -g shouldn't be
necessary, the configure scripts should add it when appropriate.

Other solutions:
Patch your gcc sources with debian's multiarch patch (Not sure if those
work for gcc 4.8):
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches=
/gcc-multiarch.diff?view=3Dmarkup
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches=
/gcc-multiarch-trunk.diff?view=3Dmarkup

Use the official debian gcc sources (GCC 4.7) which should
include this patch:
sudo apt-get install gcc-4.7-source
installs the sources at /usr/src/gcc-4.7/gcc-4.7.1-dfsg.tar.xz
Aug 02 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 2 August 2012 at 19:10:33 UTC, Johannes Pfau wrote:

 Am Thu, 02 Aug 2012 20:15:47 +0200
 schrieb "Stefan Frijters" <sfrijters gmail.com>:


 Thank you for the pointers. I just got the results of my first 
 attempt (it failed). I'm getting the same error as reported by 
 Sönke Ludwig above, and after some googling it seems to be 
 related to 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm 
 now going to retry with 'env CFLAGS="-g -O2 
 -I/usr/include/arm-linux-gnueabihf" 
 LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. 
 I put in the "-g -O2" because that is something the make 
 mentioned being there before. I guess I'll know if it worked 
 in the morning...
 
 Cheers,
 
 Stefan
 


 I didn't know the debian multiarch changes also affect 
 non-multiarch
 installations. Adding -I/usr/include/arm-linux-gnueabihf to 
 CFLAGS
 probably works (your link also suggests adding
 -B/usr/include/arm-linux-gnueabihf though). Adding -O2 -g 
 shouldn't be
 necessary, the configure scripts should add it when appropriate.

 Other solutions:
 Patch your gcc sources with debian's multiarch patch (Not sure 
 if those
 work for gcc 4.8):
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch.diff?view=markup
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff?view=markup

 Use the official debian gcc sources (GCC 4.7) which should
 include this patch:
 sudo apt-get install gcc-4.7-source
 installs the sources at /usr/src/gcc-4.7/gcc-4.7.1-dfsg.tar.xz


Thank you once more for the response. My new attempt as described
above failed as well, but for a different reason. However, it
seems I'm reinventing the wheel after all because after more
careful reading it seems I'm now running into the same problem as
Sönke Ludwig had earlier:

/home/pi/gcc-4.8-20120624/objdir/./gcc/xgcc
-B/home/pi/gcc-4.8-20120624/objdir/./gcc/
-B/opt/gdc/arm-linux-gnueabihf/bin/
-B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem
/opt/gdc/arm-linux-gnueabihf/include -isystem
/opt/gdc/arm-linux-gnueabihf/sys-include    -g -O2
-I/usr/include/arm-linux-gnueabihf -O2  -g -O2
-I/usr/include/arm-linux-gnueabihf -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include
-fPIC -fomit-frame-pointer -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fomit-frame-pointer -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include
-DHAVE_CC_TLS  -o _clear_cache.o -MT _clear_cache.o -MD -MP -MF
_clear_cache.dep -DL_clear_cache -c ../../../libgcc/libgcc2.c
In file included from ../.././gcc/tm.h:32:0,
                   from ../../../libgcc/libgcc2.c:31:
../../../libgcc/libgcc2.c: In function '__clear_cache':
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: error:
'not_used' undeclared (first use in this function)
   #define CLEAR_INSN_CACHE(BEG, END) not_used
                                      ^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
     CLEAR_INSN_CACHE (beg, end);
     ^
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: note: each
undeclared identifier is reported only once for each function it
appears in
   #define CLEAR_INSN_CACHE(BEG, END) not_used
                                      ^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
     CLEAR_INSN_CACHE (beg, end);
     ^
make[2]: *** [_clear_cache.o] Error 1
make[2]: Leaving directory
`/home/pi/gcc-4.8-20120624/objdir/arm-linux-gnueabihf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/pi/gcc-4.8-20120624/objdir'
make: *** [all] Error 2

I took a brief look at the offending macro in linux-eabi.h and it
is prefaced by a comment:

/* Clear the instruction cache from `beg' to `end'.  This is
     implemented in lib1funcs.S, so ensure an error if this
definition
     is used.  */
#undef  CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) not_used

So it seems that this crash is at least 'by design'. I will try
once more and see if I can get the multiarch patch applied.
However, at this point I have to admit I don't quite know what
I'm doing anymore, so if this fails I think I'll stick with my
squeeze image for now - even though the hard float support is
something I will need later for a hobby project I'm working on.
Again, thank you for your support.
Aug 03 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
I found some time to test some more configurations: the most 
recent version on the master branch combined with the 20120805 
snapshot of gcc 4.8 failed with the same errors as reported 
above. Using gcc 4.7.1 (both a fresh copy and a patched copy from 
the debian repo) I run into a new error. The configure reports 
two errors (which I didn't notice first time around) which then 
leads to a compilation error later:

configure:4035: arm-linux-gnueabihf-gcc -V >&5
arm-linux-gnueabihf-gcc: error: unrecognized option '-V'
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.
configure:4046: $? = 4
configure:4035: arm-linux-gnueabihf-gcc -qversion >&5
arm-linux-gnueabihf-gcc: error: unrecognized option '-qversion'
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.

Leading to (during compilation):

checking for arm-linux-gnueabihf-gcc... 
/home/pi/gcc-4.7.1/objdir/./gcc/xgcc 
-B/home/pi/gcc-4.7.1/objdir/./gcc/ 
-B/opt/gdc/arm-linux-gnueabihf/bin/ 
-B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem 
/opt/gdc/arm-linux-gnueabihf/include -isystem 
/opt/gdc/arm-linux-gnueabihf/sys-include
checking for suffix of object files... configure: error: in 
`/home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc':
configure: error: cannot compute suffix of object files: cannot 
compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/pi/gcc-4.7.1/objdir'
make: *** [all] Error 2

Some googling has told me that these are definitely connected 
somehow, but I don't know how exactly as my knowledge of the 
process fails me here. So I guess I'm just throwing it out there 
in case it will be helpful for someone else!

Cheers,

Stefan
Aug 10 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 10 Aug 2012 18:40:46 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 I found some time to test some more configurations: the most 
 recent version on the master branch combined with the 20120805 
 snapshot of gcc 4.8 failed with the same errors as reported 
 above. Using gcc 4.7.1 (both a fresh copy and a patched copy from 
 the debian repo) I run into a new error. The configure reports 
 two errors (which I didn't notice first time around) which then 
 leads to a compilation error later:
 
 configure:4035: arm-linux-gnueabihf-gcc -V >&5
 arm-linux-gnueabihf-gcc: error: unrecognized option '-V'
 arm-linux-gnueabihf-gcc: fatal error: no input files
 compilation terminated.
 configure:4046: $? = 4
 configure:4035: arm-linux-gnueabihf-gcc -qversion >&5
 arm-linux-gnueabihf-gcc: error: unrecognized option '-qversion'
 arm-linux-gnueabihf-gcc: fatal error: no input files
 compilation terminated.


You probably have to dig deeper in "config.log", as the above output
are not really errors. The configure script works with different
compilers, some use -V, some -qversion. GCC doesn't use those, it uses
-v. There should be a successful test in config.log which checked for
-v.


 
 Leading to (during compilation):
 
 checking for arm-linux-gnueabihf-gcc... 
 /home/pi/gcc-4.7.1/objdir/./gcc/xgcc 
 -B/home/pi/gcc-4.7.1/objdir/./gcc/ 
 -B/opt/gdc/arm-linux-gnueabihf/bin/ 
 -B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem 
 /opt/gdc/arm-linux-gnueabihf/include -isystem 
 /opt/gdc/arm-linux-gnueabihf/sys-include
 checking for suffix of object files... configure: error: in 
 `/home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc':
 configure: error: cannot compute suffix of object files: cannot 
 compile
 See `config.log' for more details.
 make[1]: *** [configure-target-libgcc] Error 1
 make[1]: Leaving directory `/home/pi/gcc-4.7.1/objdir'
 make: *** [all] Error 2
 


Can you paste libgcc's config.log at some pastebin? I guess
it should be
at /home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc/config.log
Aug 11 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Saturday, 11 August 2012 at 07:20:35 UTC, Johannes Pfau wrote:

 Am Fri, 10 Aug 2012 18:40:46 +0200
 schrieb "Stefan Frijters" <sfrijters gmail.com>:


 I found some time to test some more configurations: the most 
 recent version on the master branch combined with the 20120805 
 snapshot of gcc 4.8 failed with the same errors as reported 
 above. Using gcc 4.7.1 (both a fresh copy and a patched copy 
 from the debian repo) I run into a new error. The configure 
 reports two errors (which I didn't notice first time around) 
 which then leads to a compilation error later:
 
 *snip errors*


 Can you paste libgcc's config.log at some pastebin? I guess
 it should be
 at 
 /home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc/config.log


Ugh, I was in a hurry yesterday and while cleaning up some stuff 
(8GB SD card fills up mighty quickly when doing these 
compilations) I accidentally rm -rf'ed the wrong copy of the 
build, including the logs. So then I set it to compile again 
(still rushed) and now I found it's giving completely different 
errors. Moral of the story: I shouldn't try to do this sort of 
thing without ample time to check what I'm doing. As I managed to 
break some packages along the way as well while installing the 
dependencies of gcc I will now just take a step back, flash a 
fresh copy of raspbian and do the whole thing from scratch, based 
on the Debian gcc sources (4.7.1) and the gdc-4.7 branch of GDC.

Thank you for your patience!

Cheers,

Stefan
Aug 12 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Sunday, 12 August 2012 at 12:31:04 UTC, Stefan Frijters wrote:

 Ugh, I was in a hurry yesterday and while cleaning up some 
 stuff (8GB SD card fills up mighty quickly when doing these 
 compilations) I accidentally rm -rf'ed the wrong copy of the 
 build, including the logs. So then I set it to compile again 
 (still rushed) and now I found it's giving completely different 
 errors. Moral of the story: I shouldn't try to do this sort of 
 thing without ample time to check what I'm doing. As I managed 
 to break some packages along the way as well while installing 
 the dependencies of gcc I will now just take a step back, flash 
 a fresh copy of raspbian and do the whole thing from scratch, 
 based on the Debian gcc sources (4.7.1) and the gdc-4.7 branch 
 of GDC.


Ok, went through the cycle again and found another failed build 
in the morning. But at least I'm back to the same error as before 
I blew things up. Steps taken:

apt-get install gcc-4.7-source lsb-release autogen
cd /usr/src/gcc-4.7
debian/rules patch | tee patch.log
cp -r src/ /home/pi/gcc-4.7.1-debian/
swapon /dev/sda2
cd /home/pi
git clone https://github.com/D-Programming-GDC/GDC.git
cd GDC
git checkout gdc-4.7
./update-gcc.sh /home/pi/gcc-4.7.1-debian/
cd ../gcc-4.7.1-debian

patch -p1 -i ../GDC/gcc/d/patches/patch-toplev-4.7.x
cat configure | grep libphobos
mkdir objdir
cd objdir



Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 
4.6.3-8+rpi1' 
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.6 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib 
--enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --enable-plugin --enable-objc-gc 
--disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp 
--with-float=hard --enable-checking=release 
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf 
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-8+rpi1)

Here, I matched some flags to go with this gcc and went on to 
configure:

../configure --enable-languages=d --disable-bootstrap 
--disable-shared --disable-nls --prefix=/opt/gdc 
--with-bugurl="https://bitbucket.org/goshawk/gdc/issues" 
--disable-libgomp --disable-libmudflap --enable-multiarch 
--enable-linker-build-id --with-system-zlib 
--without-included-gettext --enable-threads=posix 
--enable-clocale=gnu --build=arm-linux-gnueabihf 
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf 
--with-arch=armv6 --with-fpu=vfp --with-float=hard 
--enable-checking=yes 2>&1 | tee configure.txt

Result of configure: http://pastebin.com/nznkk91w

DFLAGS="-fno-section-anchors" make 2>&1 | tee build.log

Result of make: http://pastebin.com/fW983aJ8

So now that I know where to look, the config.log of libgcc: 
http://pastebin.com/1dg8HkA1

The relevant errors seem to be

conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

This is something that is explicitly set in the configure command 
above to match what I saw in gcc -v. If I remove this, will this 
remove the advantage of having the hard floats available at all 
in Raspbian (unlike Squeeze)? Or will this be implicit anyway 
(and thus cause compilation to fail again) through the way the 
base gcc is compiled?

Cheers,

Stefan
Aug 13 2012
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Aug 2012 11:27:39 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 The relevant errors seem to be
 
 conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
 
 This is something that is explicitly set in the configure command 
 above to match what I saw in gcc -v. If I remove this, will this 
 remove the advantage of having the hard floats available at all 
 in Raspbian (unlike Squeeze)? Or will this be implicit anyway 
 (and thus cause compilation to fail again) through the way the 
 base gcc is compiled?


Not sure if it's implicit, but if your new compiler doesn't match the
system ABI strange things will happen (especially related to floating
point, using math functions from libc wouldn't work, ...)

Looks like gcc usually doesn't support -mfloat-abi=hard and
--with-fpu=vfp, but the raspbian folks patched their gcc sources to
support that. I'm not sure why they haven patched the gcc-source
package though.

You probably have to ask the raspbian folks where you can get that
patch.
You could also try to use the gcc sources from the gcc package
(apt-get source gcc), but those sources are already patched for gdc
support, so the ./update-gcc.sh script could fail.
Aug 13 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Monday, 13 August 2012 at 17:41:24 UTC, Johannes Pfau wrote:

 Am Mon, 13 Aug 2012 11:27:39 +0200
 schrieb "Stefan Frijters" <sfrijters gmail.com>:


 The relevant errors seem to be
 
 conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
 
 This is something that is explicitly set in the configure 
 command above to match what I saw in gcc -v. If I remove this, 
 will this remove the advantage of having the hard floats 
 available at all in Raspbian (unlike Squeeze)? Or will this be 
 implicit anyway (and thus cause compilation to fail again) 
 through the way the base gcc is compiled?


 Not sure if it's implicit, but if your new compiler doesn't 
 match the
 system ABI strange things will happen (especially related to 
 floating
 point, using math functions from libc wouldn't work, ...)

 Looks like gcc usually doesn't support -mfloat-abi=hard and
 --with-fpu=vfp, but the raspbian folks patched their gcc 
 sources to
 support that. I'm not sure why they haven patched the gcc-source
 package though.

 You probably have to ask the raspbian folks where you can get 
 that
 patch.
 You could also try to use the gcc sources from the gcc package
 (apt-get source gcc), but those sources are already patched for 
 gdc
 support, so the ./update-gcc.sh script could fail.


Just a small update in this - I did as you suggested and went 
over the harass the folks at the Raspbian forum. It turns out 
that there's actually an ancient version available as a package, 
but it's gdc-4.4 and doesn't even support D2, so that doesn't 
help me any at the moment. Will still to try and get the 
nitty-gritty details on their patching strategy - it looked like 
their patches were in fact in the sources package as well.
Aug 17 2012
parent reply Johannes Pfau <nospam example.com> writes:
I finally found some time to look install raspbian and have another
look at this issue. Turns out --with-float=hard and --with-fpu=vfp are
actually supported since gcc 4.5, even without patches. But theses
switches require that the gnueabi (or armeabi) is used. Now debian
uses "--target=arm-linux-gnueabihf" and although gnueabihf is just
another name used by debian for gnueabi, gcc fails to recognize this.

Debian distributes a patch with their sources to fix this. It's the
armhf-triplet.diff patch. This is actually the last patch which is
applied, so I guess some earlier patch failed and armhf-triplet.diff
was not applied.

I actually had this issue: The debian package generates the
list of used patches automatically and it seems to produce a wrong list
if the 'lsb-release' package is not installed. But I'm not sure, it
could also be necessary to install the 'debhelper' package and use
debian/build clean before patching. 

So this is what fixed it for me:
---------------------------------------------
sudo apt-get install lsb-release debhelper
apt-get source gcc-4.7
cd gcc-4.7-4.7.1

edit debian/rules.patch: comment this line:
  debian_patches += gcc-d-lang
so it should become


debian/rules clean
debian/rules patch

#clone gdc, checkout 4.7 branch
edit gcc/d/setup-gcc.sh: Edit this
-----
elif grep -q '^4\.7\.' gcc/BASE-VER; then
    gcc_ver=4.7
-----
so it becomes:
-----
elif grep -q -E '^4\.7([^0-9]|$)' gcc/BASE-VER; then
    gcc_ver=4.7
-----
(This should be fixed in the GDC repository, I'll open a pull request
soon)

Then use
./update-gcc.sh --setup /home/pi/gcc-4.7-4.7.1/src

And configure & compile gcc as usual

BTW: I think you shouldn't use --enable-multiarch when
running ../configure. It seems to cause errors in the build process and
as the system gcc didn't use it it's probably not necessary.
Aug 21 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Tuesday, 21 August 2012 at 10:16:35 UTC, Johannes Pfau wrote:

 I finally found some time to look install raspbian and have 
 another
 look at this issue. Turns out --with-float=hard and 
 --with-fpu=vfp are
 actually supported since gcc 4.5, even without patches. But 
 theses
 switches require that the gnueabi (or armeabi) is used. Now 
 debian
 uses "--target=arm-linux-gnueabihf" and although gnueabihf is 
 just
 another name used by debian for gnueabi, gcc fails to recognize 
 this.

 Debian distributes a patch with their sources to fix this. It's 
 the
 armhf-triplet.diff patch. This is actually the last patch which 
 is
 applied, so I guess some earlier patch failed and 
 armhf-triplet.diff
 was not applied.

 I actually had this issue: The debian package generates the
 list of used patches automatically and it seems to produce a 
 wrong list
 if the 'lsb-release' package is not installed. But I'm not 
 sure, it
 could also be necessary to install the 'debhelper' package and 
 use
 debian/build clean before patching.

 So this is what fixed it for me:
 ---------------------------------------------
 sudo apt-get install lsb-release debhelper
 apt-get source gcc-4.7
 cd gcc-4.7-4.7.1

 edit debian/rules.patch: comment this line:
   debian_patches += gcc-d-lang
 so it should become


 debian/rules clean
 debian/rules patch

 #clone gdc, checkout 4.7 branch
 edit gcc/d/setup-gcc.sh: Edit this
 -----
 elif grep -q '^4\.7\.' gcc/BASE-VER; then
     gcc_ver=4.7
 -----
 so it becomes:
 -----
 elif grep -q -E '^4\.7([^0-9]|$)' gcc/BASE-VER; then
     gcc_ver=4.7
 -----
 (This should be fixed in the GDC repository, I'll open a pull 
 request
 soon)

 Then use
 ./update-gcc.sh --setup /home/pi/gcc-4.7-4.7.1/src

 And configure & compile gcc as usual

 BTW: I think you shouldn't use --enable-multiarch when
 running ../configure. It seems to cause errors in the build 
 process and
 as the system gcc didn't use it it's probably not necessary.


Yes, that seems to have solved it for me as well! It's nice to 
wake up to a non-broken build for a change :-D

As I've been messing around a fair bit with my current image (not 
just D-related) I think will try to install a fresh one tonight. 
Do you think it would be useful for me to try and compile without 
the debhelper package installed, as you seem to be not completely 
sure it's needed?

Cheers,

Stefan
Aug 21 2012
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 22 Aug 2012 08:51:08 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 As I've been messing around a fair bit with my current image (not 
 just D-related) I think will try to install a fresh one tonight. 
 Do you think it would be useful for me to try and compile without 
 the debhelper package installed, as you seem to be not completely 
 sure it's needed?


Well it's not that important, in the end it's just one package more or
less to install ;-) But if you want to try building it without the
debhelper package, the "debian/rules clean" step needs debhelper, so
you should skip that step as well (It shouldn't be necessary anyway -
I'd expect the packages to be shipped in a clean state)
Aug 22 2012
prev sibling parent reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Monday, 13 August 2012 at 09:27:40 UTC, Stefan Frijters wrote:

 On Sunday, 12 August 2012 at 12:31:04 UTC, Stefan Frijters 
 wrote:

 Ugh, I was in a hurry yesterday and while cleaning up some 
 stuff (8GB SD card fills up mighty quickly when doing these 
 compilations) I accidentally rm -rf'ed the wrong copy of the 
 build, including the logs. So then I set it to compile again 
 (still rushed) and now I found it's giving completely 
 different errors. Moral of the story: I shouldn't try to do 
 this sort of thing without ample time to check what I'm doing. 
 As I managed to break some packages along the way as well 
 while installing the dependencies of gcc I will now just take 
 a step back, flash a fresh copy of raspbian and do the whole 
 thing from scratch, based on the Debian gcc sources (4.7.1) 
 and the gdc-4.7 branch of GDC.


 Ok, went through the cycle again and found another failed build 
 in the morning. But at least I'm back to the same error as 
 before I blew things up. Steps taken:

 apt-get install gcc-4.7-source lsb-release autogen
 cd /usr/src/gcc-4.7
 debian/rules patch | tee patch.log
 cp -r src/ /home/pi/gcc-4.7.1-debian/
 swapon /dev/sda2
 cd /home/pi
 git clone https://github.com/D-Programming-GDC/GDC.git
 cd GDC
 git checkout gdc-4.7
 ./update-gcc.sh /home/pi/gcc-4.7.1-debian/
 cd ../gcc-4.7.1-debian

 patch -p1 -i ../GDC/gcc/d/patches/patch-toplev-4.7.x
 cat configure | grep libphobos
 mkdir objdir
 cd objdir



 Using built-in specs.
 COLLECT_GCC=gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
 Target: arm-linux-gnueabihf
 Configured with: ../src/configure -v --with-pkgversion='Debian 
 4.6.3-8+rpi1' 
 --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
 --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
 --program-suffix=-4.6 --enable-shared --enable-linker-build-id 
 --with-system-zlib --libexecdir=/usr/lib 
 --without-included-gettext --enable-threads=posix 
 --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib 
 --enable-nls --with-sysroot=/ --enable-clocale=gnu 
 --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
 --enable-gnu-unique-object --enable-plugin --enable-objc-gc 
 --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp 
 --with-float=hard --enable-checking=release 
 --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf 
 --target=arm-linux-gnueabihf
 Thread model: posix
 gcc version 4.6.3 (Debian 4.6.3-8+rpi1)

 Here, I matched some flags to go with this gcc and went on to 
 configure:

 ../configure --enable-languages=d --disable-bootstrap 
 --disable-shared --disable-nls --prefix=/opt/gdc 
 --with-bugurl="https://bitbucket.org/goshawk/gdc/issues" 
 --disable-libgomp --disable-libmudflap --enable-multiarch 
 --enable-linker-build-id --with-system-zlib 
 --without-included-gettext --enable-threads=posix 
 --enable-clocale=gnu --build=arm-linux-gnueabihf 
 --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf 
 --with-arch=armv6 --with-fpu=vfp --with-float=hard 
 --enable-checking=yes 2>&1 | tee configure.txt

 Result of configure: http://pastebin.com/nznkk91w

 DFLAGS="-fno-section-anchors" make 2>&1 | tee build.log

 Result of make: http://pastebin.com/fW983aJ8

 So now that I know where to look, the config.log of libgcc: 
 http://pastebin.com/1dg8HkA1

 The relevant errors seem to be

 conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

 This is something that is explicitly set in the configure 
 command above to match what I saw in gcc -v. If I remove this, 
 will this remove the advantage of having the hard floats 
 available at all in Raspbian (unlike Squeeze)? Or will this be 
 implicit anyway (and thus cause compilation to fail again) 
 through the way the base gcc is compiled?

 Cheers,

 Stefan


Don't use the bitbucket issue page to file bugs. This will be 
turned off soon. ;-)


Other than that I seem to be hitting the same error doing a 
cross-compiler on the first attempt, so I guess we could figure 
something out.
Aug 30 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Thursday, 30 August 2012 at 08:02:36 UTC, Iain Buclaw wrote:

 Don't use the bitbucket issue page to file bugs. This will be 
 turned off soon. ;-)

 Other than that I seem to be hitting the same error doing a 
 cross-compiler on the first attempt, so I guess we could figure 
 something out.


Well, for me the problems have now been solved with Johannes 
Pfau's instructions on the gdcproject.org wiki (which, 
incidentally, sets --with-bugurl="http://gdcproject.org/bugzilla" 
too).

A question though: will the gdc-4.7 branch be updated to the 
2.060 frontend at any point? I don't suppose I can just 
cherry-pick the single "Update D Frontend to 2.060" commit from 
master :-D

Cheers,

Stefan
Aug 30 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2012 10:40, Stefan Frijters <sfrijters gmail.com> wrote:

 On Thursday, 30 August 2012 at 08:02:36 UTC, Iain Buclaw wrote:

 Don't use the bitbucket issue page to file bugs. This will be turned off
 soon. ;-)

 Other than that I seem to be hitting the same error doing a cross-compiler
 on the first attempt, so I guess we could figure something out.



 Well, for me the problems have now been solved with Johannes Pfau's
 instructions on the gdcproject.org wiki (which, incidentally, sets
 --with-bugurl="http://gdcproject.org/bugzilla" too).

 A question though: will the gdc-4.7 branch be updated to the 2.060 frontend
 at any point? I don't suppose I can just cherry-pick the single "Update D
 Frontend to 2.060" commit from master :-D

 Cheers,

 Stefan


4.8 is currently what I'm testing...

The multiarch-trunk patch applies cleanly to gcc-4.8, just building
with that at the moment.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 30 Aug 2012 11:12:25 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 4.8 is currently what I'm testing...
 
 The multiarch-trunk patch applies cleanly to gcc-4.8, just building
 with that at the moment.


You also need the armhf-triplet.diff patch to fix the "conftest.c:1:0:
sorry, unimplemented: -mfloat-abi=hard and VFP" error.

Or you could just build with --target=arm-linux-gnueabi instead of
arm-linux-gnueabihf, according to some old discussion there's no real
difference between those two (the relevant options are --with-fpu and
--with-float)
Aug 30 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2012 11:25, Johannes Pfau <nospam example.com> wrote:

 Am Thu, 30 Aug 2012 11:12:25 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 4.8 is currently what I'm testing...

 The multiarch-trunk patch applies cleanly to gcc-4.8, just building
 with that at the moment.


 You also need the armhf-triplet.diff patch to fix the "conftest.c:1:0:
 sorry, unimplemented: -mfloat-abi=hard and VFP" error.

 Or you could just build with --target=arm-linux-gnueabi instead of
 arm-linux-gnueabihf, according to some old discussion there's no real
 difference between those two (the relevant options are --with-fpu and
 --with-float)


Ah, cool. Well that's me finishing building it.  I'll push porting
patches into the repo.  It works in my head, could you give it a test?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2012 13:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 11:25, Johannes Pfau <nospam example.com> wrote:

 Am Thu, 30 Aug 2012 11:12:25 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 4.8 is currently what I'm testing...

 The multiarch-trunk patch applies cleanly to gcc-4.8, just building
 with that at the moment.


 You also need the armhf-triplet.diff patch to fix the "conftest.c:1:0:
 sorry, unimplemented: -mfloat-abi=hard and VFP" error.

 Or you could just build with --target=arm-linux-gnueabi instead of
 arm-linux-gnueabihf, according to some old discussion there's no real
 difference between those two (the relevant options are --with-fpu and
 --with-float)


 Ah, cool. Well that's me finishing building it.  I'll push porting
 patches into the repo.  It works in my head, could you give it a test?

 --
 Iain Buclaw

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



https://github.com/D-Programming-GDC/GDC/commit/03e34f8124eb1c607ffee11630c8ec6809b8f52c

Built with the following patches:
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/armhf-triplet.diff
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff

There will be a failed patch in libgcc, don't worry about it, as it's
already been applied to gcc-4.8.

You'll need to run 'autoconf2.64' in the gcc and libjava directories
after applying to update the configure scripts.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2012 13:20, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 13:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 11:25, Johannes Pfau <nospam example.com> wrote:

 Am Thu, 30 Aug 2012 11:12:25 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 4.8 is currently what I'm testing...

 The multiarch-trunk patch applies cleanly to gcc-4.8, just building
 with that at the moment.


 You also need the armhf-triplet.diff patch to fix the "conftest.c:1:0:
 sorry, unimplemented: -mfloat-abi=hard and VFP" error.

 Or you could just build with --target=arm-linux-gnueabi instead of
 arm-linux-gnueabihf, according to some old discussion there's no real
 difference between those two (the relevant options are --with-fpu and
 --with-float)


 Ah, cool. Well that's me finishing building it.  I'll push porting
 patches into the repo.  It works in my head, could you give it a test?

 --
 Iain Buclaw

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



 https://github.com/D-Programming-GDC/GDC/commit/03e34f8124eb1c607ffee11630c8ec6809b8f52c

 Built with the following patches:
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/armhf-triplet.diff
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff

 There will be a failed patch in libgcc, don't worry about it, as it's
 already been applied to gcc-4.8.

 You'll need to run 'autoconf2.64' in the gcc and libjava directories
 after applying to update the configure scripts.


Built with:

../gcc-4.8/configure --prefix=/usr --enable-languages=d --disable-nls
--disable-shared --disable-libgomp --disable-libmudflap
--disable-bootstrap --with-arch=armv6 --with-fpu=vfp --with-float=hard
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabihf


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2012
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2012 13:21, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 13:20, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 13:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 30 August 2012 11:25, Johannes Pfau <nospam example.com> wrote:

 Am Thu, 30 Aug 2012 11:12:25 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 4.8 is currently what I'm testing...

 The multiarch-trunk patch applies cleanly to gcc-4.8, just building
 with that at the moment.


 You also need the armhf-triplet.diff patch to fix the "conftest.c:1:0:
 sorry, unimplemented: -mfloat-abi=hard and VFP" error.

 Or you could just build with --target=arm-linux-gnueabi instead of
 arm-linux-gnueabihf, according to some old discussion there's no real
 difference between those two (the relevant options are --with-fpu and
 --with-float)


 Ah, cool. Well that's me finishing building it.  I'll push porting
 patches into the repo.  It works in my head, could you give it a test?

 --
 Iain Buclaw

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



 https://github.com/D-Programming-GDC/GDC/commit/03e34f8124eb1c607ffee11630c8ec6809b8f52c

 Built with the following patches:
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/armhf-triplet.diff
 http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff

 There will be a failed patch in libgcc, don't worry about it, as it's
 already been applied to gcc-4.8.

 You'll need to run 'autoconf2.64' in the gcc and libjava directories
 after applying to update the configure scripts.


 Built with:

 ../gcc-4.8/configure --prefix=/usr --enable-languages=d --disable-nls
 --disable-shared --disable-libgomp --disable-libmudflap
 --disable-bootstrap --with-arch=armv6 --with-fpu=vfp --with-float=hard
 --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
 --target=arm-linux-gnueabihf


Cleaned it up a little bit. :-)

https://github.com/D-Programming-GDC/GDC/commit/fc612602259bd98b28041d11a57ed99c849d1166

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
 On 30 August 2012 13:12, Iain Buclaw <ibuclaw ubuntu.com> 
 wrote:
 There will be a failed patch in libgcc, don't worry about it, 
 as it's
 already been applied to gcc-4.8.






Built it overnight with GDC a7e719a on 2012-08-16-wheezy-raspbian 

fine.

Johannes, I noticed that you already updated the Wiki to include 
this new method. Maybe it would be good to add the fact that one 
of the Debian patches will partially fail, and that it's nothing 
to worry about? Otherwise it might confuse people who have not 
read this thread (the tutorials have also been linked from the 
Raspbian wiki).
Sep 01 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 01 Sep 2012 09:49:51 +0200
schrieb "Stefan Frijters" <sfrijters gmail.com>:


 On 30 August 2012 13:12, Iain Buclaw <ibuclaw ubuntu.com> 
 wrote:
 There will be a failed patch in libgcc, don't worry about it, 
 as it's
 already been applied to gcc-4.8.






 
 Built it overnight with GDC a7e719a on 2012-08-16-wheezy-raspbian 

 fine.
 
 Johannes, I noticed that you already updated the Wiki to include 
 this new method. Maybe it would be good to add the fact that one 
 of the Debian patches will partially fail, and that it's nothing 
 to worry about? Otherwise it might confuse people who have not 
 read this thread (the tutorials have also been linked from the 
 Raspbian wiki).


OK, done. But it's a wiki, feel free to edit the pages yourself ;-)
Sep 01 2012
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
On Saturday, 1 September 2012 at 14:33:23 UTC, Johannes Pfau 
wrote:

 OK, done. But it's a wiki, feel free to edit the pages yourself 
 ;-)


Ah, sorry. I was under the impression that although it's a wiki, 
only you and Iain had the permissions to edit.
Sep 01 2012
parent "Jonathan A Dunlap" <jdunlap outlook.com> writes:
Bumping this old thread... what's the current state of D working 
with Raspberry Pie? Has the process of compiling changed?

Thanks :)
Sep 26 2013