[fedora-arm] dietlibc port?

[omalleys at msu.edu]

Quoting Gordan Bobic <gordan at bobich.net>:

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