Bug#561046: ITP: gcc-arm -- The GNU C Compiler (cross-compiler for ARM targets)
hector.oron@gmail.com wrote:
>
> How 'arm-none-eabi' differ from 'arm-linux-gnueabi' besides C library?
> Can 'arm-linux-gnueabi' be used in most 'arm-none-eabi' use cases?
It is technically possible to use an arm-linux toolchain where one would
normally use an arm-none toolchain. But there are subtle differences
between the two at the library interface level, I have found that the
*-linux toolchain tends to depend on library functions that bare-metal
systems often don't have.
It's also a matter of clarity for developers. "Why would I want a
*-linux toolchain, I'm not building for a Linux target".
> Emdebian is a group of people. This group tries to dignify Debian to
> be used for embedded targets (not fork, nor port). There are many
> tools (scratchbox, qemu, cross toolchains, apt-cross, dpkg-cross,
> emdebian-{tools, rootfs, grip, *}) emdebian people is working on.
Yes, and they are all fabulous. Particularly if you are trying to
manage Debian in cross-platform environments. But they aren't
particularly optimal for what the OP is trying to accomplish, which is
to produce a toolchain that can be used as a starting point for a
bare-metal application.
> Currently, avr, mingw32 and z80 tools (maybe some others) are in the
> main archive, but those were uploaded without any coherence in mind
> (afaict) and these tools might need to be adapted to newer layouts
> (see multiarch[1][2] or upstream sysroot -which depends on modifying
> dpkg-cross-) or removed from the archive.
> We also should *keep in mind not to polute Debian main with a bunch of
> crossgcc-tools* for each individual case (which could grow up to
> hundreds different configurations) but to have a distribution
> crosstoolchain (built in most cases and when possible with Debian
> defaults)
I like the idea of having cross toolchain packages that are "sociable"
with the Debian system. However, that really isn't a consideration for
a binutils-arm-none toolchain: its work products are by definition not
compatible with Debian--- or even Linux. So the concerns for this
situation come down to making sure that his packaging approach is
consistent with other Debian packages for non-Debian toolchains, AFAICT.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: