Opened 7 years ago

Closed 7 years ago

#15702 closed defect (fixed)

Error installing package gcc-4.7.3.p1 on ARM boards

Reported by: wluebbe Owned by:
Priority: minor Milestone: sage-6.2
Component: build Keywords: Raspberry Pi, armv6l gcc
Cc: jpflori Merged in:
Authors: Jean-Pierre Flori Reviewers: Wilfried Luebbe
Report Upstream: N/A Work issues:
Branch: 9f3a73e (Commits, GitHub, GitLab) Commit: 9f3a73e90f9b034b16f42953c60cd573891315c6
Dependencies: Stopgaps:

Status badges

Description

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 ...

Attachments (4)

install.log.gz (186.9 KB) - added by wluebbe 7 years ago.
install.log from failing gcc build on Raspberry Pi
gcc-4.7.3.p1.log.gz (127.2 KB) - added by wluebbe 7 years ago.
Error log file of gcc (with: GCC_CONFIGURE="--with-fpu=vfp" ./sage -i gcc)
gcc-4.7.3.p1.log-hard-2.gz (127.2 KB) - added by wluebbe 7 years ago.
Latest error log with the float=hard modification.
atlas-3.10.1.p7.log.gz (77.0 KB) - added by wluebbe 7 years ago.
Log of failed atlas build.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 7 years ago by jpflori

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?

Changed 7 years ago by wluebbe

install.log from failing gcc build on Raspberry Pi

comment:2 Changed 7 years ago by wluebbe

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

comment:3 Changed 7 years ago by jpflori

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

comment:4 Changed 7 years ago by jpflori

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

comment:5 Changed 7 years ago by wluebbe

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

Changed 7 years ago by wluebbe

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

comment:6 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:7 Changed 7 years ago by wluebbe

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.

Changed 7 years ago by wluebbe

Latest error log with the float=hard modification.

comment:8 Changed 7 years ago by jpflori

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.

comment:9 Changed 7 years ago by wluebbe

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 ... :-)

Changed 7 years ago by wluebbe

Log of failed atlas build.

comment:10 Changed 7 years ago by wluebbe

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.

comment:11 Changed 7 years ago by jpflori

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.

comment:12 Changed 7 years ago by jpflori

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.

comment:13 Changed 7 years ago by jpflori

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]'

comment:14 follow-up: Changed 7 years ago by 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

comment:15 in reply to: ↑ 14 Changed 7 years ago by jpflori

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.

comment:16 Changed 7 years ago by jpflori

  • Authors changed from Wilfried Luebbe to Jean-Pierre Flori
  • Branch set to u/jpflori/ticket/15702
  • Commit set to 7663187b1d343ebf07c9e94fdd211e80c367d01b
  • Keywords armv6l added; armv6 removed
  • Status changed from new to needs_review

New commits:

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

comment:17 Changed 7 years ago by git

  • Commit changed from 7663187b1d343ebf07c9e94fdd211e80c367d01b to 9f3a73e90f9b034b16f42953c60cd573891315c6

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

9f3a73eAdd support for ARMv7 boards using hard floats to gcc package.

comment:18 Changed 7 years ago by jpflori

  • Summary changed from Error installing package gcc-4.7.3.p1 on Raspberry Pi (armv6l) to Error installing package gcc-4.7.3.p1 on ARM boards

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

comment:19 Changed 7 years ago by wluebbe

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.

comment:20 Changed 7 years ago by wluebbe

  • Status changed from needs_review to positive_review

comment:21 Changed 7 years ago by vbraun

  • Reviewers set to Wilfried Luebbe

comment:22 Changed 7 years ago by vbraun

  • Branch changed from u/jpflori/ticket/15702 to 9f3a73e90f9b034b16f42953c60cd573891315c6
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.