You are asking me to justify my unreasoning personal prejudices with facts...
Actually, my complaint is about eglibc too, since it is now obsolete and replaced with mainstream glibc. Not sure about how to go about incorporating that though.
Best web comparison I have found of ulibc and eglibc is:
Comparison of C/POSIX standard library implementations for Linux
We have already had one gentleman report precision problems, which I think are due to ulibc.
Using eglibc on Galileo, this program:
#include <iostream>
#include <stdlib.h>
#include <limits>
using namespace std;
int main(int argc, char * argv[])
{
float a = 1.23456789012345;
double b = 1.23456789012345;
long double c = 1.23456789012345L;
cout << "Float: " << std::numeric_limits<float>::digits10 << endl;
cout << "Double: " << std::numeric_limits<double>::digits10 << endl;
cout << "Long Double: " << std::numeric_limits<long double>::digits10 << endl;
cout.precision(19);
cout << "A = " << a << ", B = " << b << ", c = " << c << endl;
}
produces output when run::
Float: 6
Double: 15
Long Double: 18
A = 1.234567880630493164, B = 1.234567890123450029, c = 1.23456789012345
I don't think that will happen on a ulibc image, and I am concerned that 80287 support will not work
with ulibc.
I may be all wet - it would not be the first time.
Added:
I am getting somewhat sick of looking at generated assembler code - but I did verify:
g++ -mfpmath=387 -ffast-math precision.cpp pumps out 80387 code. That is a win - and not easy to determine.