[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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.


Bill Gatliff

Reply to: