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
next sibling 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 =?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 next sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


 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 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 =?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
prev sibling next sibling parent 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=


 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=


 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=


 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
prev sibling next sibling parent 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 :-)

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
prev sibling 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 "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
prev sibling next sibling parent 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.

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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
 

it should be at /home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc/config.log
Aug 11 2012
prev sibling next sibling parent "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
prev sibling next sibling parent "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 cat configure | grep libphobos # Patch indeed missing patch -p1 -i ../GDC/gcc/d/patches/patch-toplev-4.7.x cat configure | grep libphobos mkdir objdir cd objdir gcc -v # To check for the current flags 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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_patches += gcc-d-lang

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
prev sibling next sibling parent "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_patches += gcc-d-lang

 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
prev sibling next sibling 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 next sibling parent "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 cat configure | grep libphobos # Patch indeed missing patch -p1 -i ../GDC/gcc/d/patches/patch-toplev-4.7.x cat configure | grep libphobos mkdir objdir cd objdir gcc -v # To check for the current flags 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling 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 next sibling parent 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
prev sibling next sibling parent "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 updated to 3.2.27+ #96 PREEMPT and it seems to have worked just 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
prev sibling next sibling parent 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 updated to 3.2.27+ #96 PREEMPT and it seems to have worked just 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
prev sibling next sibling parent "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
prev sibling 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