On Monday 15 March 2010 19:32:40 Denys Vlasenko wrote: > On Monday 15 March 2010 23:00, Rob Landley wrote: > > In current git: > > > > git checkout -f && git clean -fdx && make defconfig && make > > > > CC libbb/loop.o > > In file included from /usr/include/asm/types.h:4, > > from /usr/include/linux/loop.h:27, > > from libbb/loop.c:17: > > /usr/include/asm-generic/int-ll64.h:27: error: conflicting types for > > ‘bb_hack___s64’ > > include/fix_u32.h:38: error: previous declaration of ‘bb_hack___s64’ was > > here /usr/include/asm-generic/int-ll64.h:28: error: conflicting types for > > ‘bb_hack___u64’ > > include/fix_u32.h:33: error: previous declaration of ‘bb_hack___u64’ was > > here make[1]: *** [libbb/loop.o] Error 1 > > make: *** [libbb] Error 2 > > > > Denys, why did you need to mess with this? > > Do you really think I change files just for fun? > > Do you think people send emails where they _lie_ > that loop.c fails to compile for them?
No, I just think that trying to make linux/loop.h work on BSD is inherently a waste of time. The "losetup" utility is in the "Linux System Utilities" directory. It's not a posix API, this is a bug workaround for BSD's Linux emulation that complicates (and breaks) Linux. There's no doubt about where the bug _is_ in that case, and it's not in BusyBox. > > It was simple, and it worked > > without bothering us for years. If BSD can't properly emulate a Linux > > API that says "linux" in the header name, this is BSD's problem. > > You broke "make > > defconfig" using the Ubuntu 9.04 host toolchain on the current clean git > > repository. > > Please try current git. I added this to fix_u32.h: The trivial fix is to remove the #include fix_u32.h and then it works JUST FINE. This entire file is > /* Try hard to pull in u32 types and such. > * Otherwise, #include "fix_u32.h" + #include <linux/foo.h> > * may end up typedef'ing bb_hack_u32 inside foo.h, > * and repeated typedefs aren't allowed in C/C++. > */ > #include <asm/types.h> > #include <linux/types.h> 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. (And if you're not on linux, why the heck are you including a linux/*.h header?) You're messing around with the guts of the kernel headers. This break stuff. The kernel headers change from version to version. You're adding unnecessary coplexity to do something that isn't busybox's job. If your toolchain is outputting broken assembly, you fix the toolchain. Why are screwed up headers any different? > /* In case above includes still failed to provide the types, > * provide them ourself > */ > > > I spent months getting this can of worms closed last time. Don't try to > > "fix" broken toolchains, you just break non-broken toolchains and > > complicate the hell out of the code in the process. > > Of course, Ubuntu 9.04 toolchain is not broken, In that 1.2.2 still builds on it? Yes, it is not broken. > it's perfect in every imaginable way. That's a different statement, and a straw man. > It will never need any fixes. If the Ubuntu toolchain was broken, the ubuntu toolchain would need to be fixed. This breakage is not the ubuntu toolchain. This breakage is busybox doing something stupid. > All such problems are only in the past. There were a large number of problems in loop.c and similar back when we tried to hack our way around broken kernel headers, before we figured out that was a dumb thing to do. Kind of reminds me of: http://www.neatorama.com/2010/03/08/the-lost-cure-for-scurvy/ > Or maybe whenever the first problem with it will be found, What exactly would this "problem" be? Previous versions of busybox build. This is a known working toolchain. The toolchain is what changed, busybox is what changed. The changes in busybox are what caused the breakage. That's not "finding a problem in the toolchain", that's "breaking busybox by changing busybox". > we will declare it obsolete and say that whoever sits on it > is screwed and we are not going to cater for their ridiculous > demands to support it. Your strawman argument is wandering way off into the wilderness. Things that #include linux/*.h need working kernel headers. If they haven't got working kernel headers, they can't build things that #include linux/*.h. Making said kernel headers work is a toolchain issue, not a busybox issue. This is not a new observation. It has been true for years. Not every bug is a busybox bug. Attempting to work around other people's bugs adds complexity to busybox, and can introduce bugs into busybox (such as this one), and there are times when it is clearly not worth it. This is one of those times. > I'm sure users will love this attitude. Apparently you missed this thread back in 2006 where we spent a couple dozen messages figuring out what minimum requirements we need out of a C compiler: http://lists.busybox.net/pipermail/busybox/2006-May/021552.html If your kernel headers don't work, your toolchain is broken. I thought that one was kind of obvious. (The kernel headers are now exported _by_the_kernel_. The kernel defines what the headers should be. That's not BusyBox's job.) Seems really a obvious and straightforward position to me... 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
