Bug 766166

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:

http://people.redhat.com/~dhowells/cross/cross-gcc-4.6.2-1.fc16.1.1.src.rpm

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:

http://people.redhat.com/~dhowells/cross/cross-gcc.spec

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:

http://people.redhat.com/~dhowells/cross/cross-gcc-4.7.0-0.11.1.fc16.src.rpm
http://people.redhat.com/~dhowells/cross/cross-gcc-470.spec

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:

http://people.redhat.com/~dhowells/cross/cross-gcc-4.7.0-0.11.2.fc16.src.rpm
http://people.redhat.com/~dhowells/cross/cross-gcc-470.2.spec

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
Owners: dhowells
Branches: f16 f17
InitialCC:

Git done (by process-git-requests).

cross-binutils-2.22.52.0.1-8.1.fc16, cross-gcc-4.7.0-0.11.4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/cross-binutils-2.22.52.0.1-8.1.fc16,cross-gcc-4.7.0-0.11.4.fc16

cross-binutils-2.22.52.0.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]
enable libgcc

(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 >= 2.20.51.0.2-12, in RHEL6 is  2.20.51.0.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.