From mboxrd@z Thu Jan 1 00:00:00 1970 From: mjn3@codepoet.org (Manuel Novoa III) Subject: Re: New version of Bob's C compiler Date: Thu, 25 Jul 2002 14:36:11 -0600 Sender: linux-8086-owner@vger.kernel.org Message-ID: <20020725203611.GA7007@codepoet.org> References: <20020725163814.GC2577@codepoet.org> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Riley Williams Cc: ELKS Hi Riley, On Thu, Jul 25, 2002 at 08:56:25PM +0100, Riley Williams wrote: > My original reply actually mis-read the question - I was referring to > converting ELKS to require the latest BCC compiler, and my instincts say > that we're being far too hasty at this point, and need to wait until the > new BCC version is in general circulation before we do so. However, if > the general concensus is that we should do so, I will fall in line. Ah. I too misunderstood. I thought you were talking about mentioning in the ELKS docs where to find the latest bcc. I remember you had asked me that very question several weeks ago. > >> Who wants to conduct a poll to decide whether this is a good or bad > >> idea? I can see viewpoints both ways... > >> > >> FOR: Much of ELKS becomes simpler with the latest facilities. > > > I for one need the new features. ;-) > > I could make good use of them as well...but that is pretty much > irrelevant to this discussion as we can already make use of the new > facilities in our own projects whether we use them in ELKS or not. True. As I said above, I misunderstood. > >> AGAINST: ELKS becomes dependent on having the latest BCC compiler. > > > Is this really much of a drawback? Building bcc isn't that big > > an issue. > > Are you willing to be the one to deal with all the "ELKS doesn't > compile" spam that will result from the people who download ELKS onto > their system, then try to compile it and it throws up lots of error > messages simply because they have an old version of BCC installed and > we rely on a new version with lots of enhancements not in the commonly > installed versions? Not even _remotely_ likely. ;-) I see too much of that nonsense already on the busybox and uClibc mailing lists. I've got no patience for it. > I'm not - I had enough of that from HarKal when ELKS was sensitive to > a difference between his system configuration and mine with the result > that it compiled here but not on his system. We sorted that out a while > back and removed the said sensitivity from ELKS, but this will bring in > far more sensitivities than I'm willing to deal with. > > As far as I can tell, RedHat issues a new release about every six weeks > from what I've seen, and the other major distributors appear to issue > releases at about the same rate. Also, apart from the major Linux > developers (like myself), most Linux users I know keep their systems > updated to within three releases of the current one. > > My proposal would therefore be to work towards getting the BCC with > these major enhancements included in all the major distributions, then > give that four months to percolate through the userbase. At that point, > 90%+ of the Linux userbase will have the relevant compiler, and we can > start making changes that depend on those facilities without worrying > about problems like this. No matter what, there will need to be some test in the ELKS build that waives a red flag for those trying to use an old version of bcc. We still see posts from people on the uClibc mailing list about bugs in the older uC-libc that is being packaged with uClinux by some groups. Just the other day, someone posted a message about printf behavior that I fixed in uClibc over 18 months ago. :-( Manuel