On Monday, February 17, 2014 14:35:24 Christopher Meng wrote:
> 2014-2-17 PM1:42 "Mike Frysinger" <[email protected]>:
> > what is this "we" business ?  lots of people use uClibc, and that isn't
> > the problem here.  in fact, building 2013.62 w/uClibc works just fine for
> > me.
> 
> Lots of people don't use it as well.

i never said everyone uses it whereas you said "we don't use it".  there is no 
collective "we" that you can speak authoritatively for.

> Thus many people can't help since we
> can't be in the same environment like his basically, then we are impossible
> to find the problem as the conditions are not the same.

sorry that is bs.  getting a system using uClibc instead of glibc is not hard 
at all (there are released distros based on it) which means it is not 
"impossible".  further, it doesn't take a whole lot of deductive reasoning to 
think about the problem and where the issue actually lies.

> But never because of not tied to Linux.

i have no idea what that means.  uClibc is a C library, not a kernel.

> > the problem is that Steve's kernel headers are broken.  he didn't say what
> > version he's using, but i'm guessing ancient considering that header was
> > fixed in the 2.6.29 release to include linux/types.h correctly.
> 
> Maybe, but who knows this exactly especially when we(don't you?) don't know
> about the details.

well, my response was a lot more reasonable/useful than your dismissive one 
line response
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to