Rob Landley schrieb: > On Friday 14 November 2008 09:42:50 walter harms wrote: >> hhhmmm, >> >> releasing a code that depends on a libc version that is not released yet >> it not nice to users. > > I suspect glibc had this years ago and that's what they were testing against. > > I also note that uClibc had an -rc1, -rc2, and -rc3 in the month of october, > and had stated on the mailing list the intention to have a release out at the > end of October. In reality, the busybox 1.13.0 and uClibc 0.9.30 releases > were essentially synonymous. > hi Rob,
that may be but if you require the latest feature of the latest release you should give the users a hint. >> something like >> >> if uClibc version < 0.9.30 >> you need version 0.9.30 at least >> exit >> end if >> >> may help also. > > For a single applet? (Other applets build fine against much older versions.) > > Would you like to add tests for dietlibc, newlib+libgloss, and klibc as well? > > Plus the various BSDs people occasionally send in patches for, MacOS X, and > mingw? > > Plus the various non-x86 targets with varying functionality, such as the fact > you can't build taskset on m68k under _any_ libc due to the lack of smp > processor affinity syscalls? > > Wanna keep all of the above in sync, for each applet, for each new release of > every project? And warn about gcc versions that miscompile things on various > hardware targets? > > Or we could just avoid going down that rathole entirely, and stay simple. I > like simple... i do not call it *the solution*. Of cause you can not solve every problem. This was not intended. But you can help with obvious problems in basic stuff like ulibc. and if you aware that the last version of gcc will cause havoc why not add a warning ? With m68k i am not sure i would assume that m68k people will be aware that it has no smp processor affinity. NTL is is not our business to decide about releases. Denys is the maintainer and if he does , he does it. IMHO it is unfair to say nothing when i (i do not speak for other people) think he made a mistake. re, wh _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
