August 21, 2012
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.
August 22, 2012
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

August 22, 2012
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)
August 30, 2012
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.
August 30, 2012
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
August 30, 2012
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';
August 30, 2012
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)

August 30, 2012
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';
August 30, 2012
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';
August 30, 2012
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';