Re: Bug#561046: ITP: gcc-arm -- The GNU C Compiler (cross-compiler for ARM targets)
On Mon, Dec 14, 2009 at 07:42:35AM -0600, Bill Gatliff wrote:
> 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.
Which library functions?
I've been using toolchains built for both uclibc systems and for
Debian glibc to build bare firmware for armv4t for years now without
any trouble. It has no OS, no libc or other support, and this has
never been a problem at all.
I don't see why the toolchain would ever drag in a 'library function'
that you didn't explicitly ask it for. That's not its job, or how
it works.
> It's also a matter of clarity for developers. "Why would I want a
> *-linux toolchain, I'm not building for a Linux target".
"Why would you want to suggest to people they need 2 toolchains
when they probably only need one?"
This seems like a rather wasteful and deceptive 'clarity' to me ...
I think the current cross compilers already in the main distro should
be seen as an aberration, not a sign of best practice. There are far
too many possible permutations to build and distribute them all.
We need a much more scalable solution than just piling them all in
one at a time as one or two users find a need for each of them.
> 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.
Some evidence that is true would make it a more compelling point.
> 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.
Or maybe the concern is "do things that aren't compatible with Debian
belong in Debian at all"? But I don't really see that as being an issue
here at all. The toolchain won't bring in anything from Debian that you
didn't ask it to. If all you want is a different name, you can probably
just do that with some symlinks, but I don't personally see any advantage
to doing that either.
Cheers,
Ron
Reply to: