Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Sam Ravnborg]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/