A few weeks back there was a big discussion on fedora-devel-list about cross compilers in relation to the Fedora arm project. Somewhere in the thread I promised we (GES @ Red Hat) would put out our cross compilation bits as proof of concept. While we're still making some changes to our cross rpm packages, we can share our current cross compiler beta for those who are interested. We're producing working root filesystems with this compiler, so you should be able to as well.
A couple things to note: The tools are portion of the GNUPro toolkit currently in development (aka gnupro-07r1-1) and is not based on the sources from Fedora (It is gcc 4.2.1, for instance). We don't normally build with RPM, so the spec file is a wrapper to our rebuild program (Which handles the chicken/egg problem aka gcc/glibc).
Source and binary RPMs are available here:
ftp://ftp.ges.redhat.com/private/releng/arm-linux-beta
These were built on a 32 bit RHEL3 host. It works just as well on a x86_64 Fedora 7 box, so no worries if you want to rebuild. Unless otherwise directed, tools will install under /opt/redhat/gnupro-07r1-1/H-%{_host}/bin
To rebuild you need to define %target like so:
rpmbuild -ba --define 'target arm-linux-gnueabi' gnupro.spec
All feedback appreciated.
Brendan,
Thanks for posting this. I took a quick look. Please see comments below.
Brendan Conoboy wrote:
A few weeks back there was a big discussion on fedora-devel-list about cross compilers in relation to the Fedora arm project. Somewhere in the thread I promised we (GES @ Red Hat) would put out our cross compilation bits as proof of concept. While we're still making some changes to our cross rpm packages, we can share our current cross compiler beta for those who are interested. We're producing working root filesystems with this compiler, so you should be able to as well.
A couple things to note: The tools are portion of the GNUPro toolkit currently in development (aka gnupro-07r1-1) and is not based on the sources from Fedora (It is gcc 4.2.1, for instance). We don't normally build with RPM, so the spec file is a wrapper to our rebuild program (Which handles the chicken/egg problem aka gcc/glibc).
Okay, this is essentially how cross-tool or codesourcery would build their cross-toolchain? The scripts are different, but the idea is same. Or, am I missing something?
Our goal with this project is to actually leverage fedora. In other words, here are things I would like to be able to achieve...
1. The cross-compiler is "equivalent" to the native compiler. Thus, if I mix cross-built packages with native built packages, it should all just work.
2. When doing cross-building of packages and root file systems, we should be using the Fedora packages. This is not a problem that the cross-compiler needs to address (except for glibc), but we need to deal with it in the next step (i.e., building packages).
Could you explain how you leverage Fedora in your approach, or is that not something you particularly care about?
Thanks Manas
Okay, this is essentially how cross-tool or codesourcery would build their cross-toolchain? The scripts are different, but the idea is same. Or, am I missing something?
Not sure how those work, but...
Building a toolchain with a sys-root is a chicken and egg problem, as you need the libraries to build the compiler (esp libgcc.so), and you need the compiler to build the libraries. On a native system, you already have "some" copy of each installed, so the problem is, well, less fatal.
What we do with GNUpro is merge the source trees (at least, gcc, gdb, binutils, and maybe newlib) into a single unified tree, and build that all at once. When the target uses newlib, that means everything has what it needs at the right time, which avoids many of the dependency problems.
For glibc targets, what pretty much everyone does is "stage" the builds - building part of gcc, part of glibc, more of gcc, more of glibc, etc. There are dependencies between gcc and glibc that are difficult to resolve cleanly, but you can't just build the two of them in one source tree. Sometimes, the kernel gets involved too.
In addition, as we cross-build packages, the "-dev" versions get installed (or at least *need* to ;) into the sys-root within our install tree (/opt/redhat/gnupro-07r1-1/H-*/${target}/sys-root), overriding anything else that might be there (the bootstrap's glibc, for example) so that the tools use them for future builds.
Could you explain how you leverage Fedora in your approach, or is that not something you particularly care about?
The purpose of this package is to offer what we happen to have to the community. We're not trying to "leverage" anything or coerce people into doing things our way, just giving people an opportunity to see what we have. Perhaps it will give people ideas, maybe someone will find it useful.
We (RH) certain do care about Fedora, but the GES group specializes in cross compilers, not natives, and we maintain our own branch of the tools so we can concentrate on issues (usually bugs) specific to cross compiling.
For cross-compiling Linux rootfs's, we normally do use the Fedora packages. In the past, we've found they often need porting or other changes to work in a non-x86 non-native build. We, like you, look forward to not having to port them any more ;-)
Manas Saksena wrote:
Okay, this is essentially how cross-tool or codesourcery would build their cross-toolchain? The scripts are different, but the idea is same. Or, am I missing something?
It's essentially the same sort of solution. We wrote eBuild-Linux before cross-tool was out there (And it's grown as glibc has grown).
Our goal with this project is to actually leverage fedora. In other words, here are things I would like to be able to achieve...
Oh definitely, this is just a starting point. FWIW, gnupro-07r1 is based on gcc 4.2.latest, binutils 2.17.latest and gdb 6.6.latest. This isn't exactly Fedora 7 and it's not exactly Fedora 8, but it's really quite close.
- The cross-compiler is "equivalent" to the native compiler. Thus, if I mix cross-built packages with native built packages, it should all just work.
Sure- just to quickly rehash my goals for Fedora:
I'd like to see $TARGET-binutils and $TARGET-gcc as standard Fedora packages. For the purpose of this list, TARGET=arm-linux-gnueabi (Or some variation thereof), but what I'm ultimately after is to have as many packages as possible be cross-friendly. These cross-binutils/gcc packages *should* be based directly on the native binutils/gcc packages. There's already what is needed for binutils. With gcc, more work is needed to split the target libraries from the compiler itself. Once that is done, gcc should be relatively easy (No chicken/egg problem).
In crosstopia, there is a complete mesh of cross compilers for every Fedora architecture. Whenever there is a package to be built, whether it's for i686, arm, s390, powerpc, any host can compile it for any target. This requires the cross compilers, some enhancements to rpm, and some enhancements to Koji. It's all technically feasible, though.
There was an extensive discussion on fedora-devel-list about this. You can catch the beginning of the thread here:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html
Also Lennert's hijacked thread :-)
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00189.html
- When doing cross-building of packages and root file systems, we should be using the Fedora packages. This is not a problem that the cross-compiler needs to address (except for glibc), but we need to deal with it in the next step (i.e., building packages).
Could you explain how you leverage Fedora in your approach, or is that not something you particularly care about?
That's part 2 :-) We have an in-house build system called rpmbuildroot that uses mock and GNUPro to cross-build Fedora packages. We make some changes to the Fedora packages so they can cross build (Plus whatever is necessary architecture-wise). Sometime soon we hope to release the rpmbuildroot environment so people have access to the patches and can try out a different system.
Brendan Conoboy wrote:
Sure- just to quickly rehash my goals for Fedora:
I'd like to see $TARGET-binutils and $TARGET-gcc as standard Fedora packages. For the purpose of this list, TARGET=arm-linux-gnueabi (Or some variation thereof), but what I'm ultimately after is to have as many packages as possible be cross-friendly. These cross-binutils/gcc packages *should* be based directly on the native binutils/gcc packages. There's already what is needed for binutils. With gcc, more work is needed to split the target libraries from the compiler itself. Once that is done, gcc should be relatively easy (No chicken/egg problem).
Phew! thats what I thought you were after (from the discussions in fedora-devel). So, we are on the same page -- good!
In crosstopia, there is a complete mesh of cross compilers for every Fedora architecture. Whenever there is a package to be built, whether it's for i686, arm, s390, powerpc, any host can compile it for any target. This requires the cross compilers, some enhancements to rpm, and some enhancements to Koji. It's all technically feasible, though.
Yes.
There was an extensive discussion on fedora-devel-list about this. You can catch the beginning of the thread here:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html
Also Lennert's hijacked thread :-)
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00189.html
Yup! I remember the whole thread etc.
Could you explain how you leverage Fedora in your approach, or is that not something you particularly care about?
That's part 2 :-) We have an in-house build system called rpmbuildroot that uses mock and GNUPro to cross-build Fedora packages. We make some changes to the Fedora packages so they can cross build (Plus whatever is necessary architecture-wise). Sometime soon we hope to release the rpmbuildroot environment so people have access to the patches and can try out a different system.
Well, thats the stuff that I am interested in. And, we are just about ready to get seriously started on that front -- so hopefully you wont hold back on that for too long :-)
Manas
-
Brendan Conoboy -
DJ Delorie -
Manas Saksena