On Tuesday 16 March 2010 09:50:10 Denys Vlasenko wrote: > On Tuesday 16 March 2010 03:23, Rob Landley wrote: > > Actually the trivial fix is: > > > > diff --git a/include/fix_u32.h b/include/fix_u32.h > > index 5652e9e..2049f16 100644 > > --- a/include/fix_u32.h > > +++ b/include/fix_u32.h > > @@ -5,7 +5,7 @@ > > * > > * Licensed under the GPL version 2, see the file LICENSE in this > > tarball. */ > > -#ifndef FIX_U32_H > > +#if 0 > > #define FIX_U32_H 1 > > > > #undef __u64 > > > > I.E. "fix_u32.h" is what's breaking it in the first place. If that > > entire file did not exist, there would be no problem including linux/* > > headers Linux. > > Rob, there would be no problem _for you_, with your recent toolchain.
What does "recent" have to do with it? I just checked the toolchain in Red Hat 9, using the #if 0 thing on a snapshot from current -git. In order to build defconfig I had to switch off half of the new stuff in miscutils: inotifyd, ionice, taskset, watchdog, the flash stuff... And I switched off the whole networking directory after ifenslave broke... Actually I just did an "allnoconfig" and switched on losetup because so much was broken. But it built loop.c just fine. That's a 7 year old toolchain, so "recent" is not the correct attribute to use here. "Not obviously and profoundly broken" is how I'd describe it. The old busybox releases built using the old toolchains, since those were the only ones available at the time. My first commit to loop.c was in 2004, it tried to do something a bit like you're trying to do now, and I'm telling you from experience that it was the WRONG APPROACH: http://www.busybox.net/lists/busybox/2004-December/013276.html For several years, busybox was being built without a simple, clean loop.c that did not include your current workaround. You didn't add your workaround until eight months ago, and you labeled it "Patches to enable FreeBSD build", I.E. git commit 9b1b62adc4e4c1 on July 5, 2009. That's not an "insufficiently recent toolchain", that's "not Linux attempting to #include linux/loop.h". It's something that isn't Linux trying to use a Linux API and failing. It's an obviously flawed attempt by a different OS to provide a Linux emulation that does not function without horrible workarounds that unnecessarily complicate (and break) the original Linux it's claiming to emulate, due to a bug in the thing that isn't Linux. Its inability to actually accurately emulate Linux is not a bug in Busybox. If you feel the need to work around that (and personally I'd tell them to fix their bug instead), it would belong in platform.h, not in loop.c. > I want to support some not-exactly-perfect toolchains too. There's a difference between putting an #ifdef BSD into platform.h to detect clearly broken things, and sprinkling breakage around the rest of the code that pretends to be generic fixes for definitely-not-generic problems. > It's ok if you disagree with me on this. > IMO it's not something worthy of protracted discussion. I agree with the first statement and disagree with the second, but oh well. You're the boss... > Please let me know whether current git works for you. Your workaround for the completely unnecessary breakage you introduced curretly bypasses the issue for me at the moment, yes. Until the added unnecessary complexity breaks again in a future kernel upgrade in as yet unforseen ways. (And it will, just wait. Been there, done that.) Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
