D on the Raspberry Pi

[Iain Buclaw]

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.