Error installing package gcc-4.7.3.p1 on ARM boards

[Wilfried Luebbe]

The starting point is Installing GCC because a Fortran compiler is missing.

After

[ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library, but some functions are only in"; echo "   the static library.  */"; echo "GROUP ( libgcc_s.so.1 libgcc.a )" ) > ./libgcc_s.so

there are LOTS of messages like

/usr/bin/ld: error: ./libgcc_s.so.1.tmp uses VFP register arguments, _negdi2_s.o does not
/usr/bin/ld: failed to merge target specific data of file _negdi2_s.o
/usr/bin/ld: error: ./libgcc_s.so.1.tmp uses VFP register arguments, _cmpdi2_s.o does not
/usr/bin/ld: failed to merge target specific data of file _cmpdi2_s.o

The problem seems be a conflict between hard and soft FP (​http://stackoverflow.com/questions/9753749/arm-compilation-error-vpf-registered-used-by-executable-not-object-file).

In ​http://trac.sagemath.org/wiki/ExoticPorts jpflori also mentions hard floats.

The problem can of course easily circumvented by apt-get install gcc g++ gfortran.

Side remark: Since building Sage from source on Raspberry Pi already takes almost 5 days with the three compilers pre-installed (compared to 1 hour on my 4 core i750 desktop) - building gcc may NOT be the recommended way ...

But to avoid a build error even on an exotic platform and if there is a simple fix ...

[Jean-Pierre Flori]

I don't remember if I built GCC or not. I'd say no, for the same exact same reason you mentioned, it would already take far too much time. (And, yes I was using hard floats, with Raspbian.)

I'll still have a look at your problem, but it seems strange that GCC is not smart enough to select soft/hard floats or even build multilib. Could you post your full build log please?

[Wilfried Luebbe]

install.log from failing gcc build on Raspberry Pi

[Wilfried Luebbe]

Since install.log is only somewhat larger than gcc-4.7.3.p1.log I added the complete log.

[Jean-Pierre Flori]

Can you try recompiling using

GCC_CONFIGURE="--with-fpu=vfp" ./sage -i gcc

(Only the value of GCC_CONFIGURE actually matters.)

If that's not enough, you could try

GCC_CONFIGURE="--with-fpu=vfp --with-float=hard" ./sage -i gcc

[Jean-Pierre Flori]

Ok, I could reproduce the error on raspbian. I'll try the suggested fixes now.

[Wilfried Luebbe]

Jean-Pierre, my RaspPi? is just trying the first variant (w/o float=hard).

[Wilfried Luebbe]

Error log file of gcc (with: GCC_CONFIGURE="--with-fpu=vfp" ./sage -i gcc)

[Wilfried Luebbe]

The next run was failing, too. To be clear, here is a snippet from my current spkg-install:

if [ "$SAGE_CHECK" = yes ]; then
    # Enable internal checks in GCC.  These checks do not affect the
    # binaries produced by GCC, but they do increase the compile time
    # of everything compiled with GCC.
    ###  GCC_CONFIGURE="$GCC_CONFIGURE --enable-checking=yes"
    ## GCC_CONFIGURE="--with-fpu=vpu" ./sage -i gcc
    GCC_CONFIGURE="--with-fpu=vpu --with-float=hard" ./sage -i gcc
fi

As I started the second run (after changing spkg-install) just by calling ./make again, there were perhaps some left overs from the first run.

Therefore I am now doing a clean build with float=hard ...

PS.: The log-file is available for upload.

[Wilfried Luebbe]

Latest error log with the float=hard modification.

[Jean-Pierre Flori]

Strange, it seems you failed in the same spot.

In my tests:

• default failed
• passing only --with-fpu=vfp failed the same way (building libgcc_s.so in stage 1)
• passing both --with-fpu=vfp and -with-float=hard is still running, made it through stage 1 and is now in stage 2.

And you don't need to modify spkg-install. On top of that you removed some options from GCC_CONFIGURE (the checinkg stuff) and that is not taken into account as the snippet you modified is within a SAGE_CHECK=yes part (and thats unset by default). You can just run the ocmmand I posted above.

[Wilfried Luebbe]

Jean-Pierre, I apparently did not interpret your comment:3 correctly :-/

I just restarted building gcc (with the original, unmodified spkg-install and with

GCC_CONFIGURE="--with-fpu=vfp --with-float=hard" ./sage -i gcc

entered on the terminal.

Thanks for teaching me ... :-)

[Wilfried Luebbe]

Log of failed atlas build.

[Wilfried Luebbe]

gcc has built succesfully :-)

After that I restarted make to verify the complete build. But now atlas failed (see attached log-file):

[RunGMMSearch] Error 255 ... and thereafter some failed assertions.

[Jean-Pierre Flori]

Please don't post gzipped files on the trac server unless really necessary. Just post files which can be read directly here, otherwise, just post a link the file hosted somewhere else.

[Jean-Pierre Flori]

About the ATLAS problem, it may be gcc segfaulting because of an ICE or lack of virtual memory, but I wouldn't even try to fix that, at least not here. I'll provide a building gcc branch here first.

[Jean-Pierre Flori]

The actual ATLAS error is:

/tmp/ccXXp4W5.s: Assembler messages:
/tmp/ccXXp4W5.s:44: Error: selected processor does not support ARM mode `pld [r6,#0]'

[Jean-Pierre Flori]

Which is no problem with the system GCC. So maybe we should pass "--with-arch=armv6" to GCC_CONFIGURE as well. Testng that now

[Jean-Pierre Flori]

Replying to jpflori:

Which is no problem with the system GCC. So maybe we should pass "--with-arch=armv6" to GCC_CONFIGURE as well. Testng that now

It seems to do the trick. The problematic file now compiles. I'll just have to wait forever for ATLAS build to finish.

[Jean-Pierre Flori]

New commits:

​7663187

Let GCC 4.7.3 build on Rapsberry Pi (hard floats only).

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9f3a73e

Add support for ARMv7 boards using hard floats to gcc package.

[Jean-Pierre Flori]

Added support for armv7 (hard floats only as well).

[Wilfried Luebbe]

After applying the patch on my RaspberryPi? I could build gcc and then build the rest of Sage 6.0. ./sage -t -a resulted in 97 timeouts (which is not too surprising :-) but no errors. - I cannot test the armv7 aspect.

But it is a positive review for resolving my original defect.