On Thu, Jun 22, 2006 at 06:02:18AM +0200, Daniel Baumann wrote: > Steve Langasek wrote: > >> On hppa, the package FTBFS due to code errors.
> hppa is, hopefully, fixed with the latest upload. We'll have to wait until linux-2.6 is fixed on hppa to see, I guess. > > All three of these failures (and now sparc) are caused by the per-flavor > > modules not being available under the names the build is looking for. It > > has nothing to do with 64-bit support: first of all, there is no such > > *thing* as a 32-bit ia64 system, the architecture is natively 64-bit, and > > second, any of these archs should be able to build modules for 64-bit > i didn't say that there is a 32bit ia64 system.. You did actually, but maybe you mispoke. Anyway, > but are itanium system able to build binaries for itanium2 (mckinley) > systems? Yes, why wouldn't they be? There's only one toolchain for ia64, it will support the same targets regardless of what subarch you *run* that toolchain on. Anyway, looking at the logs, the real build failure on ia64 (at least in the current revision) is: ld: cannot open linker script file /usr/src/linux-headers-2.6.16-2-mckinley-smp/arch/ia64/module.lds: No such file or directory I don't know if this is a bug in the linux-headers or in unionfs for expecting it to be there. It /looks/ like you're calling the kernel makefile, though, which would make it a bug in linux-headers. > > So this is very much not an architecture bug to sort out, this is a bug in > > either unionfs or whatever tools it's using for building the modules. Since > > other module packages aren't reporting the same problem, it looks like a > > unionfs bug to me. > if i build the modules at home on my sparc64 and powerpc64 machine, they > build fine. as myon told me, there could be something wrong with the > 'domain exec'. need to look into that.. Possibly so; that would be a unionfs bug then, because it shouldn't be relying on the execution domain to get the architecture name right. Makefile:524: /usr/src/linux-headers-2.6.16-2-sparc64/arch/sparc/Makefile: No such file or directory That should evidently be ./usr/src/linux-headers-2.6.16-2-sparc64/arch/sparc64/Makefile, so the bug is that unionfs is getting a wrong architecture name somewhere. If it's getting that from uname -m (which is what running a build under "sparc32" would change), then yeah, it's definitely a source bug, not a bug in the build environment. Maybe a bug in the linux-headers package, though in that case I wonder how the package is able to build the sparc*32* flavor on your system. The failure on powerpc is interesting and different and unlike the others, but seems to be a problem that nothing has specified the right architecture target to gcc at any point, resulting in compile failures from trying to use 64-bit headers when compiling 32-bit code. I can't guess whether that's linux-2.6's or unionfs's bug. My initial guess would be that the kernel make rules know how to pass the right arguments to gcc, but this is being overridden by unionfs? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
