Jamie Lokier wrote:
Bill Traynor wrote:
Maybe I'm being dense, but what's specifically wrong with the current
toolchain universe?
Back in ye olde days, you could download GCC and Binutils from
gnu.org, configure for whatever is your architecture, and most times
it just worked.
For some reason, that stopped a while ago, and you had to go to
different places to get working basic tools. And often, the place to
go wasn't clear. Different people advertised their "ARM toolchain",
"m68k toolchain" etc. and they were slightly different sets of
patches on top of mainline tools. Central authorities you might
believe in existed, but they were always a few patches behind what you
actually needed.
When I last needed a toolchain, Google led to confusing results, and I
had to try more than one. I still use mutiple GCC versions (from
different people) to compile different programs for the same
architecture: each one fails some things in a different way, including
run-time failures in the precompiled toolchains.
Just Google for "uclinux toolchain" and the top hits lead to very old
releases, with bugs that have long been fixed elsewhere. "uclinux arm
toolchain" is no better.
The uClinux arm toolchain case can be put down to noone
having an interest in actually doing the work. There has been
some work over the years, but no coordinated effort for quite
a while now.
Perhaps current versions (e.g. from Codesourcery?) are more dependable
for embedded architectures, but I don't have the time to thoroughly
test them, and my last experience warns me to be careful.
It seems people release tools, release patches, publish on an obscure
web page, then forget about the page. More authoritative-sounding
uclinux web pages tend to be out of date. Google isn't finding good
current authorities in this area, which suggests the space is rather
fragmented with people pulling in different directions and not working
together enough to create stable, common places for these things.
Yep, there is a lack of "working together" when it comes to the
uclinux tool chains. You can't force people to work together.
At the very least the packages on uclinux.org give you the build
instructions, and scripts used to build them. You can try to get
newer tool versions working (with fixes if required).
Contrast with kernel.org: everyone knows where to get a good working
Linux kernel for the mainstream architectures, and the quality work
tends to be quite good at reaching mainline there nowadays.
I don't know that comparison exactly holds. kernel.org is source,
just like gnu.org is the source of gcc/binutils/etc. Are you not
talking about binary toolchain packages above?
Regards
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
