Now that we have a substantial chunk of the packages built for ARM, I think it would be interesting to see if we can build a cross-compiler that is aligned with the native toolchain. And, at this stage, we dont need to worry about bootstrapping gcc since we already have a glibc available.
I think it would be useful to bundle a cross-compiler/debugger toolchain with the release even if all the other packages are built natively. As much of the development tends to be with the kernel and the applications, the cross-compiler is virtually a necessity for those.
Is anyone interested in working on that?
Manas
On Sat, Jun 23, 2007 at 07:10:26PM -0700, Manas Saksena wrote:
Now that we have a substantial chunk of the packages built for ARM, I think it would be interesting to see if we can build a cross-compiler that is aligned with the native toolchain. And, at this stage, we dont need to worry about bootstrapping gcc since we already have a glibc available.
I think it would be useful to bundle a cross-compiler/debugger toolchain with the release even if all the other packages are built natively. As much of the development tends to be with the kernel and the applications, the cross-compiler is virtually a necessity for those.
Is anyone interested in working on that?
Sorry for the late reply -- see:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02597.html https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02739.html
Binary i386 -> ARM packages are here:
Lennert Buytenhek wrote:
On Sat, Jun 23, 2007 at 07:10:26PM -0700, Manas Saksena wrote:
Now that we have a substantial chunk of the packages built for ARM, I think it would be interesting to see if we can build a cross-compiler that is aligned with the native toolchain. And, at this stage, we dont need to worry about bootstrapping gcc since we already have a glibc available.
I think it would be useful to bundle a cross-compiler/debugger toolchain with the release even if all the other packages are built natively. As much of the development tends to be with the kernel and the applications, the cross-compiler is virtually a necessity for those.
Is anyone interested in working on that?
Sorry for the late reply -- see:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02597.html
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02739.html
Binary i386 -> ARM packages are here:
http://www.wantstofly.org/~buytenh/cross/
I was wondering if it would be possible to package this up in a way that would be easy to install.
For e.g., a cross-toolchain package, which requires all the other packages -- gcc, binutils, etc. (not sure how to deal with glibc in that context). So, you can just do:
yum install cross-toolchain-arm
and, you have everything you need.
Manas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Manas Saksena wrote:
Lennert Buytenhek wrote:
On Sat, Jun 23, 2007 at 07:10:26PM -0700, Manas Saksena wrote:
Now that we have a substantial chunk of the packages built for ARM, I think it would be interesting to see if we can build a
cross-compiler
that is aligned with the native toolchain. And, at this stage, we dont need to worry about bootstrapping gcc since we already have a glibc available.
I think it would be useful to bundle a cross-compiler/debugger
toolchain
with the release even if all the other packages are built natively. As much of the development tends to be with the kernel and the applications, the cross-compiler is virtually a necessity for those.
Is anyone interested in working on that?
Sorry for the late reply -- see:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02597.html
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02739.html
Binary i386 -> ARM packages are here:
http://www.wantstofly.org/~buytenh/cross/I was wondering if it would be possible to package this up in a way that would be easy to install.
For e.g., a cross-toolchain package, which requires all the other packages -- gcc, binutils, etc. (not sure how to deal with glibc in that context). So, you can just do:
yum install cross-toolchain-arm
and, you have everything you need.
Manas,
We have been experimenting with packaging our GNUPro tools as one big RPM. We're currently holding the One-Big-RPM vs. Multiple-Not-So-Big-RPMS debate, but we actually have built a cross toolchain and packaged it as an RPM, since you can do that in an SRPM; if you have multiple SRPMS you have to have some synchronization logic for the bootstrapping and we don't have that currently.
It's not aligned with the Fedora toolchain, but it's close. It's currently one package with gcc-4.2.1, binutils-2.17 and glibc-2.6. I'm also pretty sure it's never been built using a mock chroot, so getting all this going in koji is going to be an "interesting" exercise. But I'm willing to give it a shot. Well, me and Brendan that is :)
You interested?
Clark
On Tue, Jul 17, 2007 at 04:11:32PM -0500, Clark Williams wrote:
We have been experimenting with packaging our GNUPro tools as one big RPM. We're currently holding the One-Big-RPM vs. Multiple-Not-So- Big-RPMS debate, but we actually have built a cross toolchain and packaged it as an RPM, since you can do that in an SRPM; if you have multiple SRPMS you have to have some synchronization logic for the bootstrapping and we don't have that currently.
Binutils cross-builds trivially on its own (see David Woodhouse's binutils cross patch.)
And if you happen to be building Fedora->Fedora, you can just drop the target glibc RPM into your sysroot, and then gcc builds trivially on top of that.
Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Manas Saksena wrote:
Lennert Buytenhek wrote:
On Sat, Jun 23, 2007 at 07:10:26PM -0700, Manas Saksena wrote:
Now that we have a substantial chunk of the packages built for ARM, I think it would be interesting to see if we can build a
cross-compiler
that is aligned with the native toolchain. And, at this stage, we
dont
need to worry about bootstrapping gcc since we already have a glibc available.
I think it would be useful to bundle a cross-compiler/debugger
toolchain
with the release even if all the other packages are built
natively. As
much of the development tends to be with the kernel and the applications, the cross-compiler is virtually a necessity for those.
Is anyone interested in working on that?
Sorry for the late reply -- see:
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02597.html
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02739.html
Binary i386 -> ARM packages are here:
http://www.wantstofly.org/~buytenh/cross/I was wondering if it would be possible to package this up in a way that would be easy to install.
For e.g., a cross-toolchain package, which requires all the other packages -- gcc, binutils, etc. (not sure how to deal with glibc in that context). So, you can just do:
yum install cross-toolchain-arm
and, you have everything you need.
Manas,
We have been experimenting with packaging our GNUPro tools as one big RPM. We're currently holding the One-Big-RPM vs. Multiple-Not-So-Big-RPMS debate, but we actually have built a cross toolchain and packaged it as an RPM, since you can do that in an SRPM; if you have multiple SRPMS you have to have some synchronization logic for the bootstrapping and we don't have that currently.
What I had in mind was to have a "meta-package" that simply requires gcc, binutils, etc. So, a yum install of the "meta-package" would give you the full toolchain.
If you punt on bootstrapping (i.e., treat it as a separate problem), then it should not be that hard to maintain it. What I was hoping for was that we could use the same binutils, gcc, glibc, gdb SRPMs to build in both a cross-build and a native build environment, and that way you can make also ensure that there is no mismatch between a cross-toolchain and a native toolchain.
It's not aligned with the Fedora toolchain, but it's close. It's currently one package with gcc-4.2.1, binutils-2.17 and glibc-2.6. I'm also pretty sure it's never been built using a mock chroot, so getting all this going in koji is going to be an "interesting" exercise. But I'm willing to give it a shot. Well, me and Brendan that is :)
You interested?
Sure -- definitely worth a try. I think it would be a good idea to do the experimentation on cross-toolchain/development stuff until we reach some agreement on what makes most sense. So, if you can move some of the debate on one-big-rpm vs multiple-rpms out here, then that would be most welcome as well.
Regards, Manas
DJ Delorie wrote:
If you punt on bootstrapping
Keep in mind that our group specializes in cross compiling, so bootstrapping is not something we usually punt ;-)
What I meant was that you dont have to use the same SRPMs to do the initial bootstrap. That makes your SRPMs a bit-cleaner and they dont have to be cluttered with "bootstrap" special case.
And, once you have built your initial toolchain, you can use that to bootstrap subsequent builds. Only occasionally, you have to and do a full bootstrap all over again.
Regards, Manas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Manas Saksena wrote:
DJ Delorie wrote:
If you punt on bootstrapping
Keep in mind that our group specializes in cross compiling, so bootstrapping is not something we usually punt ;-)
What I meant was that you dont have to use the same SRPMs to do the initial bootstrap. That makes your SRPMs a bit-cleaner and they dont have to be cluttered with "bootstrap" special case.
And, once you have built your initial toolchain, you can use that to bootstrap subsequent builds. Only occasionally, you have to and do a full bootstrap all over again.
Regards, Manas
I see a difference in philosophy developing already :)
In general we bootstrap all the time, since we're trying to ensure that all the pieces work together. Either that or we're incredibly pedantic. Probably both...
The advantage of bootstrapping every time is that you know all the parts were built with the same set of assumptions. It's not nearly as bad as bootstrapping a native, since you don't have the stageN steps to manage.
For my part, I see much more potential for configuration problems with trying to mix-n-match the set of arm-linux-gcc, arm-linux-binutils, arm-linux-glibc and potentially arm-linux-gdb packages, than just bootstrapping everything into one arm-linux-crosstools package.
To be fair, I suppose your counter is that my approach would make it harder to track the fedora tools. Hmmmm, I'll have to think about that.
Clark
Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Manas Saksena wrote:
DJ Delorie wrote:
If you punt on bootstrapping
Keep in mind that our group specializes in cross compiling, so bootstrapping is not something we usually punt ;-)
What I meant was that you dont have to use the same SRPMs to do the initial bootstrap. That makes your SRPMs a bit-cleaner and they dont have to be cluttered with "bootstrap" special case.
And, once you have built your initial toolchain, you can use that to bootstrap subsequent builds. Only occasionally, you have to and do a full bootstrap all over again.
Regards, Manas
I see a difference in philosophy developing already :)
I actually agree with your philosophy. And, have lived that life in my past job, where we built everything from scratch in a known controlled environment.
But, I am also trying to balance that with the goal of having a large (if not all) part of fedora built for ARM, staying synchronized with the Fedora package base, and having native toolchains etc.
In general we bootstrap all the time, since we're trying to ensure that all the pieces work together. Either that or we're incredibly pedantic. Probably both...
The advantage of bootstrapping every time is that you know all the parts were built with the same set of assumptions. It's not nearly as bad as bootstrapping a native, since you don't have the stageN steps to manage.
For my part, I see much more potential for configuration problems with trying to mix-n-match the set of arm-linux-gcc, arm-linux-binutils, arm-linux-glibc and potentially arm-linux-gdb packages, than just bootstrapping everything into one arm-linux-crosstools package.
But, surely, you could have a bootstrap build script that builds a bootstrap gcc and then builds the rest of the toolchain srpms. And, then you have a fully controlled build environment that can track the native fedora versions quite well.
To be fair, I suppose your counter is that my approach would make it harder to track the fedora tools. Hmmmm, I'll have to think about that.
Yes, unfortunately. I believe that if you are building any reasonable subset of Fedora natively, you simply cant do a fully automated bootstrap due to circular dependencies etc. OTOH, when you cross-build, you can probably get along further.
So, my thinking is that as we bring in the cross-build capability incrementally, we dont unnecessarily fork packages from the main fedora base. Otherwise, you end up with a different distro/toolset, of which there are plenty of them.
What I would also like is to make sure that whatever we do, we dont take the full build from scratch/bootstrap option away. So, for e.g., if someone wants to build the toolchain and a set of packages completely in a cross-build environment, they should be able to build the whole thing from scratch. I am assuming that if we have that, then that would serve your needs. And, I know that there will be cases where we would want to do that as well.
And, maybe one day we would be able to build the entire distro in a fully automated, built from scratch manner as well.
Regards, Manas
-
Clark Williams -
DJ Delorie -
Lennert Buytenhek -
Manas Saksena