From owner-freebsd-hackers Mon Jan 29 21:20:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA25080 for hackers-outgoing; Mon, 29 Jan 1996 21:20:00 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA25071 for ; Mon, 29 Jan 1996 21:19:54 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id VAA07386; Mon, 29 Jan 1996 21:18:55 -0800 From: Julian Elischer Message-Id: <199601300518.VAA07386@ref.tfs.com> Subject: Re: Better to back out the change to crt0 To: cimaxp1!jb@werple.net.au (John Birrell) Date: Mon, 29 Jan 1996 21:18:55 -0800 (PST) Cc: hackers@freebsd.org In-Reply-To: <199601300319.OAA21109@werple.net.au> from "John Birrell" at Jan 30, 96 02:18:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > Julian, > > I guess that Jordan's attitude is clear. We either fix the 'make world' > problem or back out the change. I've looked at fixing it and I see that > Nate has too. Michael Smith had offered to do a few trial builds on his > system (that subsequently went up in smoke). I can offer a machine that I'm presnetly setting up by tomorrow hopefully I will have a 2.2-current system up and on the net for exactly this > > The change to crt0 doesn't break -current as far as the code goes, but > the bogus build procedure that FreeBSD uses is incapable of working out > the correct dependencies and 'make world' breaks because of that. I suggest > that it would be advisable to back out the change to crt0. To fix the > bogus build is a big deal because the current software design principles > are fundamentally flawed (you can't avoid race conditions). The only way > I can see to get the crt0 change into the source tree without breaking the > first 'make world' after it is committed is to find some way of patching > the installed libc. Yuk. > > By backing out the change to crt0, we maintain the status quo - we don't > move forward - we don't move backward. All that will happen is that > people will stop yelling. Sigh. Ok but it means that we don't have a way to initialise the threads code.... Terry had an alternative suggestion, do you reember what it was? julian > > Regards, > > -- > John Birrell CIMlogic Pty Ltd > jb@cimlogic.com.au 119 Cecil Street > Ph +61 3 9690 6900 South Melbourne Vic 3205 > Fax +61 3 9690 6650 Australia > Mob +61 18 353 137 >