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.
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.
I've updated to gcc-4.7.0-RC-20120302 and made more arches available. Revised SRPM and specfile can be found here:
Created attachment 571743 [details]
rpmlint of the most recent SRPM and built RPM files
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.
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.
Created attachment 571807 [details]
rpmlint for cross-gcc-4.7.0-0.11.2.fc16.src.rpm and co,
Looks good. Review passed; thanks.
New Package SCM Request
Package Name: cross-gcc
Short Description: Cross-compilation gcc set
Branches: f16 f17
Git done (by process-git-requests).
cross-binutils-126.96.36.199.1-8.1.fc16, cross-gcc-4.7.0-0.11.4.fc16 has been submitted as an update for Fedora 16.
cross-binutils-188.8.131.52.1-8.1.fc16, cross-gcc-4.7.0-0.11.4.fc16 has been pushed to the Fedora 16 testing repository.
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.
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.
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 ...
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
Created attachment 585215 [details]
(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.
(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?
requirement for libmpc from spec file is >= 0.8.1, while in EPEL is 0.8, which gcc says is bugy, but usable.
another requirement is binutils >= 184.108.40.206.2-12, in RHEL6 is 220.127.116.11.2-5. gcc says nothing, when binutils is same version but older release.
Created attachment 606258 [details]
spec file for RHEL6 compilation
spec file with change for RHEL6
This package was imported and built for a very long time. All other questions and issues should be discussed in a separate rhbz tickets.