Bug 766166 - Review Request: cross-gcc - Multiple cross-build gcc
Summary: Review Request: cross-gcc - Multiple cross-build gcc
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Fedora Extras Quality Assurance
Depends On: 761619
TreeView+ depends on / blocked
Reported: 2011-12-10 18:55 UTC by David Howells
Modified: 2019-01-09 12:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-11-26 16:24:19 UTC
Type: ---
dwmw2: fedora-review+
gwync: fedora-cvs+

Attachments (Terms of Use)
rpmlint of the most recent SRPM and built RPM files (2.52 KB, application/x-bzip)
2012-03-21 15:26 UTC, David Howells
no flags Details
rpmlint for cross-gcc-4.7.0-0.11.2.fc16.src.rpm and co, (2.13 KB, application/x-bzip)
2012-03-21 18:26 UTC, David Howells
no flags Details
enable libgcc (2.91 KB, patch)
2012-05-17 13:08 UTC, Dan Horák
no flags Details | Diff
spec file for RHEL6 compilation (19.86 KB, text/plain)
2012-08-22 13:01 UTC, Jiri Kastner
no flags Details

Description David Howells 2011-12-10 18:55:05 UTC
Spec URL: http://people.redhat.com/~dhowells/cross/cross-gcc.spec
SRPM URL: http://people.redhat.com/~dhowells/cross/cross-gcc-4.6.2-1.fc16.1.src.rpm

I've taken the Fedora 16 gcc specfile and modified it greatly so that it builds a cross-compiler for a number of the Linux kernel arches (some of them don't build) and packages each one up in its own binary RPM (named gcc-<targetcpu>-linux-gnu).

The working targets are: alpha, arm, blackfin, h8300, m32r, m68k, mips (32/64, be/le), mn10300, parisc(hppa/hppa64), powerpc (32 & 64), s390/s390x, sh4, sparc (32/64), x86_64/i386 and xtensa.  Note that I've built the 64-bit targets to include the 32-bit targets, so, for instance, you have to use the x86_64-linux-gnu compiler to build i386 stuff.

The packages are configured with "--program-prefix=<targetcpu>-linux-gnu-".  Note
that the name passed to "--target" may not match the program prefix (for instance h8300-linux-gnu is targeted to h8300-elf).

As the manual pages and help files are emitted into the core binary RPM and a dependency is emplaced.  Note that these filenames overlap with the core gcc - which isn't a problem as long as the programs are the same version.  However, it may be worth dropping them entirely from the package and just including a dependency on the Fedora core gcc package.

This depends on the cross-build binutils package up for review in bug 761619.

I would appreciate a review so that I can get this into Fedora Extra.

Many thanks,

Comment 1 David Howells 2012-01-10 23:35:41 UTC
I've fixed the warnings that can be fixed; I have left the dangling symlink
warnings as they refer are cross-package references to the common manual pages,
and, after asking advice, I've left the hardlinks in.

The revised SRPM can be found here:


I've tacked on an extra bit to the revision ID to retain the revision number of
the Fedora binutils package from which I derived this whilst adding a
differentiator for my own changes.

The revised specfile can be found here:


Note that this is the same place as the previous one, which has been renamed.

Comment 2 David Howells 2012-03-15 18:06:33 UTC
I've updated to gcc-4.7.0-RC-20120302 and made more arches available. Revised SRPM and specfile can be found here:


Comment 3 David Howells 2012-03-21 15:26:06 UTC
Created attachment 571743 [details]
rpmlint of the most recent SRPM and built RPM files

Comment 4 David Woodhouse 2012-03-21 16:15:53 UTC
Lots of rpmlint warnings about stuff being commented out. As discussed on IRC, please try using %if 0 to comment stuff out. Or better still, don't comment it out at all. The closer we stick to the native toolchain package, the better.

Comment 5 David Howells 2012-03-21 18:25:07 UTC
Okay.  New versions uploaded:


I've applied the rawhide patches where appropriate and deleted the ones that are now rolled into the snapshot tarball I'm using.

I've dealt with all the macro-in-comment warnings that aren't inherited from the rawhide gcc specfile.

Comment 6 David Howells 2012-03-21 18:26:33 UTC
Created attachment 571807 [details]
rpmlint for cross-gcc-4.7.0-0.11.2.fc16.src.rpm and co,

Comment 7 David Woodhouse 2012-03-21 21:40:14 UTC
Looks good. Review passed; thanks.

Comment 8 David Howells 2012-03-22 09:50:53 UTC
New Package SCM Request
Package Name: cross-gcc
Short Description: Cross-compilation gcc set
Owners: dhowells
Branches: f16 f17

Comment 9 Gwyn Ciesla 2012-03-22 12:32:49 UTC
Git done (by process-git-requests).

Comment 10 Fedora Update System 2012-03-23 12:16:06 UTC
cross-binutils-, cross-gcc-4.7.0-0.11.4.fc16 has been submitted as an update for Fedora 16.

Comment 11 Fedora Update System 2012-03-24 00:29:13 UTC
cross-binutils-, cross-gcc-4.7.0-0.11.4.fc16 has been pushed to the Fedora 16 testing repository.

Comment 12 Dan Horák 2012-04-06 08:51:33 UTC
David, could you build sh-linux-gnu tools instead of (or in addition to) the sh4-linux-gnu one? It seems that the sh4 gcc is able to generate only sh4 code, while the sh one would generate code for whole SH family. And the reason I'm asking is that sh-linux-gnu would be able to build carl9170 wifi firmware (uses sh2 cpu, http://linuxwireless.org/en/users/Drivers/carl9170) from sources and I've offered a help to Josh Boyer and John Linville. John even submitted sh-elf toolchain for review, but it seems redundant, because I'm able to compile the firmware successfully with sh4-linux-gnu, it won't work obviously due the different CPU.

Comment 13 Lucas Stach 2012-05-15 09:30:54 UTC
I'm using this package to build the U-Boot bootloader for ARM platforms. This works well as long as the compiled modules only use the U-Boot internal libgcc, but some of the modules require a libgcc provided by the toolchain.

So my question is: what would it take or is it even feasable to provide a cross-libgcc along with the cross-gcc and cross-binutils packages? This would make the existing cross packages a lot more useful for embedded hardware bringup development.

Comment 14 Dan Horák 2012-05-17 08:28:15 UTC
In theory building libgcc could be matter of simply adding "all-target-libgcc" to the existing "all-gcc" in the build_target function, but the real life is usually more colourful ...

Comment 15 Dan Horák 2012-05-17 11:19:00 UTC
OK, only 3 issues found
- ia64 - needs stdlib.h, included from unwind.h (host system header)
- m68k - needs asm/unistd.h, but in fact there is a fallback when the value needed is not defined, I have a one-liner for it
- tilegx - needs arch/icache.h

Comment 16 Dan Horák 2012-05-17 13:08:07 UTC
Created attachment 585215 [details]
enable libgcc

Comment 17 David Howells 2012-06-01 09:22:47 UTC
(In reply to comment #13)
> So my question is: what would it take or is it even feasable to provide a
> cross-libgcc along with the cross-gcc and cross-binutils packages? This
> would make the existing cross packages a lot more useful for embedded
> hardware bringup development.

The problem is that adding userspace is massively multiplicative, especially for some arches.  Some libgccs won't build without bits of kernel headers or C library headers - and there are multiple C libraries that would have to be included in the SRPM as not all arches are supported by all C libraries.  At least I'd probably have to include glibc and uClibc.

And then, which libgccs do we build?  MIPS, for example, has half a dozen, I think, and FRV has three or four.

It may be possible to cheat and only include a few headers and not build shared-library libgccs.

It may even be worth considering build userspace packages for certain useful combinations if we can keep the list small.

However, my primary objective is to build as many compilers as I can for the purpose of building the Linux kernel - even if I can't *link* the kernel due to the lack of a libgcc.

Comment 18 Lucas Stach 2012-06-05 07:37:37 UTC
(In reply to comment #17)

I may be a bit off here, but I don't think we need any libc to build libgcc and I agree that it's not a good idea to add any userspace to this compiler package.

But I'm only interested in this package to generate bare-metal binaries like the kernel or a bootloader. This is not possible currently as gcc generates calls to libgcc to implement specific routines. Bare-metal binaries shouldn't need any libc or something similar, just a statically linkable libgcc.a.

With this information in mind could you please re-evaluate this request?

Comment 19 Jiri Kastner 2012-08-22 12:56:38 UTC
requirement for libmpc from spec file is >= 0.8.1, while in EPEL is 0.8, which gcc says is bugy, but usable.

Comment 20 Jiri Kastner 2012-08-22 12:59:15 UTC
another requirement is binutils >=, in RHEL6 is gcc says nothing, when binutils is same version but older release.

Comment 21 Jiri Kastner 2012-08-22 13:01:28 UTC
Created attachment 606258 [details]
spec file for RHEL6 compilation

spec file with change for RHEL6

Comment 22 Peter Lemenkov 2012-11-26 16:24:19 UTC
This package was imported and built for a very long time. All other questions and issues should be discussed in a separate rhbz tickets.

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