Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > Andy Green wrote: > >>>> Sounds like you found a solution ^^ >>> >>> It's a solution for me, but from tthe philosophical point of view, there >>> is probably the greater issue of the distribution to consider. Is >>> dietlibc really that useful on a non-embedded distribution (yes, I know >>> I'm referring to the ARM port of something as non-embedded)? What really >> >> Well a major reason to rely on a distro with a well-stocked repo of >> binaries is that you can just use them, and other people have been >> banging on them and fixing them too. The prebuilt stuff is all built >> against glibc so that's a strong reason to stick with that. > > The point I was getting to was that the stock of packages at least in > the base distro should be consistent across platforms, except in very > hardware-specific cases (e.g. there's probably no point in having grub > on ARM or uboot on x86). uboot on x86 would be nice... :P Although so would a shipping A9MP chip... :) I agree with the jist of what you are saying. I also understand the first time you work through the code, you are going to find arch specific bugs, that aren't easy to solve and need to be pushed upstream to the source to get fixed and I am guessing most projects don't have a lot of ARM support. >>> concerns me is that it doesn't build on x86 either, at which point I >>> can't but question what the point of having it in the current state is >>> at all. >> >> Dunno. However I do know that there is a lot of politics at least in >> the past around glibc >> >> http://www.google.com/#hl=en&source=hp&q=glibc+drepper+arrogant >> >> ... so it wouldn't surprise me if it's in the distro as a hedge on that >> as much as anything else. Debian/Ubuntu switched to eglibc which is a "variant" of glibc for embedded systems. They tend to accept more patches. It is compatible wherever possible and they do push changes to the mainline glibc. I think it started mainly because they couldnt get patches put in mainline fast enough and they needed less bloat for embedded like dietlibc. I thought Damn Small Linux, and the Linux router project used dietlibc but I could be wrong or they may have switched to eglibc too. Maybe dietglibc is abandon or folded into eglibc. > It seriously makes you wonder how come there isn't a better, less > politically encumbered libc around. The really vexing thing about the > situation is that both glibc and dietlibc are very gcc specific. This > rather precludes the possibility of having an entire distro built with > another (better) compiler. The Intel compiler's performance boosts of 800% you are seeing are really the SSE optimisation routines. Which Intel is insanely good at it and kudos to them, but they also make the hardware. If you DO find places in the code where gcc doesn't autovectorize the code properly, please report the code segments as bugs to the gcc group. They need to be aware of the issue so it can be fixed it. GCC supports a lot more platforms and it might not be the fastest compiler on a specific platform. But it isn't a complete dog either. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
