uClibc with Linux 2.6.8 Headers
amckay at iders.ca
Thu Jul 19 14:09:31 UTC 2007
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.
More information about the uClibc