View mode: basic / threaded / horizontal-split · Log in · Help
August 02, 2012
Re: D on the Raspberry Pi
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
-----------
August 02, 2012
Re: D on the Raspberry Pi
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
August 02, 2012
Re: D on the Raspberry Pi
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
August 03, 2012
Re: D on the Raspberry Pi
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.
August 10, 2012
Re: D on the Raspberry Pi
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
August 11, 2012
Re: D on the Raspberry Pi
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
August 12, 2012
Re: D on the Raspberry Pi
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
August 13, 2012
Re: D on the Raspberry Pi
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
August 13, 2012
Re: D on the Raspberry Pi
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.
August 17, 2012
Re: D on the Raspberry Pi
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.
1 2 3 4
Top | Discussion index | About this forum | D home