Hi,
Loïc Minier wrote:
I'd like to understand your use cases to make sure we're on track to cover them. First, we're trying to maintain a toolchain source tree which is adequately patched; that's mostly launchpad.net/gcc-linaro right now. Second, we're integrating that into the native Ubuntu toolchain. Third, we're providing a cross-toolchain to install in Ubuntu environments. The latter two are built from the same source, which includes the gcc-linaro tree.
Sounds good.
Is this what you're looking for, or do you need more? What were the specific cases which you experienced which required different toolchain?
Things I can think of, but I don't know how important they are:
- being able to easily change the default toolchain build flags (how do
you get the toolchain? which flags do you use?)
In OSELAS.Toolchain, we have a set of flags integrated into each toolchain, so for example for arm-v4t-linux-gnueabi, it generates v4t code with software floating point without any further flags. I agree on that it would be a goal to have only one multilib toolchain which can do everything, but we definitely need wrappers, because compiling a hello world should still be
$(GCC) hello.c -o hello
- being able to easily drop patches into the toolchain (how do you get the toolchain? which kind of patches?)
Well, nobody wants patches if you can avoid them. The question is what to do with things which cannot be brought into the upstream. It is sometimes a very long lasting thing to try to convince the upstream of certain patches. So we need patches in the toolchains for the forseable future. What we also need is better collaboration with the upstream maintainers.
For us, patches are also a thing which is important if problems arise. With OSELAS.Toolchain, we already had the case toolchains had to be patched right in a project, and nobody had the time to wait until there is a new distro package available. Throwing in a patch and rebuilding is easy, but I think it is probably as easy to do that with Debian packets once that's the standard way.
Btw, the current work-in-progress patch queue from OSELAS.Toolchain is here:
http://git.pengutronix.de/?p=rsc/OSELAS.Toolchain.git%3Ba=tree%3Bf=patches%3...
Unfortunately, it still contains several underdocumented patches (mainly from Gentoo and OpenEmbedded). For ARM it is only slightly tested with v4t and arm1136.
- being able to roll your own toolchain packages from another toolchain tree
- providing RPM packages for native and cross toolchains
I would be interested in if it was possible to have the cross toolchains so decoupled from the rest of the distro that they can be run on Debian/Ubuntu/RedHat/SuSE.
- providing tarball "packages" with "standalone" linux binaries,
similar to CS toolchain downloads
Would also be easy. Our customers quite often don't care about the development box at all, they just take what some random decision mechanism says (i.e. a project member who has already experience with distro x.y). So in order to come to a well defined environment, we usually install the toolchain in /opt and ptxdist does the rest.
On Thu, Sep 02, 2010 at 03:23:17PM -0400, Jon Smirl wrote:
This question should be asked on a list with more embedded ARM integrators, like the linux-arm kernel list or the open embedded list. I've fowarded it to the Pengutronix developers. I'm an end user of the tools, the bigger picture is to get the companies putting together BSPs for embedded ARM systems to stop rolling their own compilers.
I'm all for this goal. Building toolchains is a lot of useless effort. In the end, we are no toolchain people, but we still have to do this in order to get our work done.
Getting a tool chain with into Ubuntu with broad target support should be enough to get the ball rolling.
Right. I would be even more happy to get these things into Debian as well.
An unrelated thing that is missing is a universal configuration tool for putting together Linux images. Pengutronix has modified kconfig to do this but every dev system is different. The basic idea is a menu system that lets you pick what packages you want in your flash image. Open embedded does this with bitbake, etc, etc...
I doubt it will be possible to get consense about this topic, because the requirements are too different. Let's start with toolchains and patch upstreaming - I think if these topics are solved, we have gained a lot.
rsc