From owner-freebsd-current Thu Sep 30 17:32:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from adsl-63-195-54-213.dsl.snfc21.pacbell.net (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id EE48714BD0 for ; Thu, 30 Sep 1999 17:32:34 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by adsl-63-195-54-213.dsl.snfc21.pacbell.net (8.9.1/8.8.7) id RAA16199; Thu, 30 Sep 1999 17:32:29 -0700 (PDT) Message-ID: <19990930173229.61526@hydrogen.fircrest.net> Date: Thu, 30 Sep 1999 17:32:29 -0700 From: John-Mark Gurney To: Nate Williams Cc: Marcel Moolenaar , Peter Wemm , current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed References: <19990930003214.58194@hydrogen.fircrest.net> <19990930195614.2834A1CA7@overcee.netplex.com.au> <19990930135119.29632@hydrogen.fircrest.net> <37F3D522.2A4C79C2@scc.nl> <19990930163945.56976@hydrogen.fircrest.net> <199909302344.RAA01090@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199909302344.RAA01090@mt.sri.com>; from Nate Williams on Thu, Sep 30, 1999 at 05:44:25PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams scribbled this message on Sep 30: > > you don't under stand, we are NOT talking about upgrades, we are talking > > about how to make a buildable system on -stable... > > There are essentially the same problem. In order to do an upgrade, you > have to be able to build on -stable. :) yes, they are the "same problem", but they are viewed differently.. w/ an upgrade, you can requre ANYTHING to happen, this includes having to install and reboot w/ 10 different kernels before you reach your destination... which makes the last part impossible... > > ===> libgcc > > echo '#include ' > config.h > > echo '#include ' >> config.h > > echo '#include "i386/xm-i386.h"' > tconfig.h > > echo '#include "i386/i386.h"' > tm.h > > echo '#include "i386/att.h"' >> tm.h > > echo '#include "i386/freebsd.h"' >> tm.h > > echo '#include "i386/perform.h"' >> tm.h > > cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > > cc1: Invalid option `-fexceptions' > > This is unrelated to the signal code. Why are you jumping on Marcel for > this? this is what preceeded the above snip it in my original message that Nate deleted: > > and so you know, (this is unrelated to the -current > > tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and > > have it succeed: he suggested that I try a make buildworld -DNOTOOLS to see if that would work, I was simply reporting that it failed to work... notice that I said: "this is unrelated to the -current tools running on -stable" part... > In any case, I believe there is work in progress as well as interest in > making *something* work. Let's all quit yelling at one another and > start working towards a solution, instead of pointing fingers and > screaming 'he broke it and won't fix it'. :) P.S. It is really hard for me to not make personal attacks against you after all of the above and completely ignoring the rest of my message. Simply pointing out behavior problems is not going to solve anything. So, why don't you read the last part of my message that you felt like ignoring, and provide input? The last part included a possible solution to the problem. since you seem to have completely ignored the last part of my message, here it is again: ok, the problem is: a) -current tools are built w/ -current libc and friends b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message