On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: > > Rob Landley wrote: > >On Thursday 12 March 2009 17:40:02 Geert Uytterhoeven wrote: > >>On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > >>>>And, yes, I can confirm the m68k include/asm/unistd.h from linux-next > >>>>actually has contents, thanks to commit > >>>>646652bded41f4c3bd375b4e03a25b42da93f40b > >>>> > >>>>Anyway, here's hoping the fix makes it into 2.6.29. > >>>Why not telling the m68k maintainer that you think it should go into > >>>2.6.29? > > > >I contacted the headers_install maintainer about a headers_install > >problem, and was pointed to an existing fix upstream. This seemed to > >imply awareness of the problem? > > > >Happy to follow up more, wasn't aware it was required... > > > >>There are a few more: > >> > >>param.h:#include "param_no.h" > >>param.h:#include "param_mm.h" > >>ptrace.h:#include "ptrace_no.h" > >>ptrace.h:#include "ptrace_mm.h" > >>setup.h:#include "setup_no.h" > >>setup.h:#include "setup_mm.h" > >>sigcontext.h:#include "sigcontext_no.h" > >>sigcontext.h:#include "sigcontext_mm.h" > >>siginfo.h:#include "siginfo_no.h" > >>siginfo.h:#include "siginfo_mm.h" > >>signal.h:#include "signal_no.h" > >>signal.h:#include "signal_mm.h" > >>swab.h:#include "swab_no.h" > >>swab.h:#include "swab_mm.h" > >> > >>Rob, do these also causes problems? > >>Some (not all) of them are fixed in linux-next. > > > >I'm trying to build uClibc against the new headers. I just got around to > >extracting the patch to fix that one file and testing it in my build > >system, and this time it broke with: > > > > build/cross-compiler-m68k/include/asm/param.h:4:22: error: param_mm.h: No > > such file or directory > > > >So yeah, it's still unhappy. Dunno how many of these are still needed to > >build the cross compiler, and then who knows what other packages need to > >build. Presumably all of it. > > > >Keep in mind I still haven't found an emulator for m68k that actually > >boots a linux kernel, so my m68k support is purely theoretical. (I poked > >at mess and uae a bit today, but they don't do the "qemu -kernel" thing > >I'm using for the other targets, and qemu itself only seems to support > >coldfire and not a full- > >blown m68k.) I'm following up on this because it's a regression. Under > >2.6.28 the m68k target was building a kernel and root filesystem, but I > >don't have hardware to run it and have never been able to test it, so > >isn't really very useful for me. It's really just there so that if qemu > >grows the rest of m68k support (patches have been submitted but not > >merged), I'll be ready. > > > >P.S. If you're bored and want to try my test build for yourself: > > > > wget http://impactlinux.com/hg/firmware/archive/tip.tar.bz2 > > tar xvjf tip.tar.bz2 > > cd firmware-* > > USE_UNSTABLE=linux ./build.sh m68k > > > >Without the USE_UNSTABLE=linux it uses 2.6.28 and builds to completion, > >with it the build uses 2.6.29-rc7 (or whatever URL's listed as the > >UNSTABLE= value for linux in download.sh) and it breaks trying to add > >uClibc to the cross compiler. > > > >But then anything that actually _uses_ the "make headers_install" output > >to build stuff against should notice pretty quickly whether or not it > >#includes missing files. > > I pretty quick time I can fix up the last couple on the above list. > But do we want to put all that change into 2.6.29-rc at this point? In general we do not want to have headers_check broken in mainline, so if this is what is required to fix it then yes. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
