uClibc with Linux 2.6.8 Headers

[Andrew McKay]

Ken Moffat wrote:
>  I'm not the man who can help you on the stated problem, but I can
> query some of your details and perhaps remind you of some debugging
> techniques - maybe that will help, maybe not.

Oops, I thought I had replied to my previous email, I guess I forgot to press 
Reply-All.  I stopped thinking that the toolchain itself was a problem.  Finally 
tracked the problem down to some of the build scripts I had written myself that 
builds the ramdisk for my system.  I was pointing to one compiler with my PATH 
variable in a script to build Busybox, and then had the path pointing to a 
second compiler (the wrong one) when I ran make install on busybox.  The second 
compiler decided that it needed to relink Busybox, and broke the executable.

> 
> 3.  2.6.8 is not only prehistoric, it long predates the kernel's own
> headers.  If you are really using 2.6.8 headers, it might help if
> you explained where they come from (I'm not even sure if
> linux-libc-headers was around in those days).  Your version of gcc
> (at least, from an x86/x86_64/ppc perspective) is very old, so maybe
> you do mean 2.6.8, but I suspect a typo for 2.6.18 ?

No I did mean 2.6.8, I know it's old, but Cirrus Logic usually takes their time 
on releasing patches for the Linux Kernel.  I haven't had time recently to see 
if they have updated patches or not yet.  I'm sure they're a couple of versions 
up now, but they're definitely never bleeding edge.  I'm hoping that the 
community effort for Cirrus Logic parts will soon be stable enough for our use. 
  I'm currently talking to my boss about freeing up some of my development time 
to help out with the effort.  Any way to by pass Cirrus Logic's slow patches 
would be a good thing for us I think

> 
> 4.  You haven't mentioned your architecture.

My architecture is ARM.

Anyways, thanks for taking the time to reply, and sorry for the noise on the list.

Andrew McKay
Iders Inc.