> 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. Yes, the difficulty is in the "configure" step. But the GNU Toolchain is a complex beast but the benefit is it flexibility and numerous supported architectures. Ye olde days perhaps was less complex, but also less flexible and supporting less archs. > > 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. I disagree with respect to ARM. GNU toolchains for ARM have for the last four or five years been relatively up to date for ARM hardware. This is a direct result of ARM paying for this support to be added. > > 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. You didn't have to try more than one, you chose to try more than one. You could have just as easily chosen to use only the current mainline GNU toolchain and worked through your issues with the community, thereby allowing mainline to benefit from your fixes, and you to benefit by getting to use the most current toolchain. > > 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 "fixed elsewhere" is the problem. If everyone used the most current release and worked through issues with the community, this problem would go away. > > 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. I know from experience, having worked for CodeSourcery that their toolchains are exhaustively tested. And any problems reported to their public mailing lists are fixed, if legitimate. These fixes are typically submitted upstream to the FSF very quickly when the bugs exist in mainline as well. > > 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. But isn't the FSF repositories for the GNU Tools, and the uClinux projects repositories the stable, common place for these things? > > 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. IMHO, the same is true for the GNU toolchain. > > -- Jamie > -- > To unsubscribe from this list: send the line "unsubscribe linux-embedded" > in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
