Bug 917749 - aarch64 gcc build
Summary: aarch64 gcc build
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-04 17:18 UTC by Mark Salter
Modified: 2015-02-22 17:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-22 17:08:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
specfile changes (3.87 KB, patch)
2013-03-04 17:18 UTC, Mark Salter
no flags Details | Diff
config update for aarch64 (12.44 KB, patch)
2013-03-04 17:19 UTC, Mark Salter
no flags Details | Diff

Description Mark Salter 2013-03-04 17:18:23 UTC
Created attachment 705078 [details]
specfile changes

Description of problem:

I have successfully built gcc-4.8.0-0.12 in a bootstrap environment with some small tweaks to the specfile and one other patch. Patches attached.

The specfile changes deal mostly with adding %bcond_without java and %bcond_without docs to make it easier to leave those things out of build without having to edit the spec file.

There was one patch needed to update config.{sub,guess} in isl so that it recognized aarch64.

There is also a kludgy bit of %install script to put aarch64 shared libs in /usr/lib64. Even though aarch64 doesn't have multilib support, Fedora does use /usr/lib64 for shared libs but the makefiles put everything in /usr/lib. Not sure if that is okay or if some other patch is needed.


Version-Release number of selected component (if applicable):

gcc-4.8.0-0.12

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Mark Salter 2013-03-04 17:19:43 UTC
Created attachment 705082 [details]
config update for aarch64

Comment 2 Jakub Jelinek 2013-03-07 11:22:19 UTC
The isl config update is fine, but most of the gcc.spec changes look either wrong or undesirable to me.
For /usr/lib64 on aarch64, I think you need something like
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00288.html
(but the patch is really untested so far, I don't have access to aarch64).
The spec already has stuff to deal with bootstrapping java for the first time, you should use what is documented in the spec file and after bootstrapping for the first time just keep using older compilers to build newer ones.
The libstdc++ docs hacks you can apply yourself temporarily, but I don't want that clutter, bootstrapping the distro for a new arch always will require some manual process.
Why are you not using profiledbootstrap on aarch64?  Has it failed to build that way?

Comment 3 Mark Salter 2013-03-07 14:16:01 UTC
Thanks for the comments. Fair enough on the bootstrapping bits. I'm not exactly wanting to bootstrap java now which is why the extra added bits there. The reality we face atm is that there is no hardware and the gcc build takes 6 days on the sim. My thought on the profiledbootstrap was that it would take longer than the non-profiled build and trying it could be left for a later build.

Thanks for the lib64 patch. I will put it in and start another build using the profiledbootstrap.

Comment 4 Fedora End Of Life 2013-04-03 15:07:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 5 Brendan Conoboy 2013-12-02 23:11:47 UTC
The gcc in rawhide fails to build for aarch64 due to fastjar's outdated config.guess and config.sub.  Can these be refreshed?

See: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2169976


Note You need to log in before you can comment on or make changes to this bug.