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;a=tree;f=patches;hb=refs/heads/gcc-4.5
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
