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
