Date: Thu, 30 Sep 1999 16:39:45 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Marcel Moolenaar <marcel@scc.nl> Cc: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed Message-ID: <19990930163945.56976@hydrogen.fircrest.net> In-Reply-To: <37F3D522.2A4C79C2@scc.nl>; from Marcel Moolenaar on Thu, Sep 30, 1999 at 11:24:50PM %2B0200 References: <19990930003214.58194@hydrogen.fircrest.net> <19990930195614.2834A1CA7@overcee.netplex.com.au> <19990930135119.29632@hydrogen.fircrest.net> <37F3D522.2A4C79C2@scc.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar scribbled this message on Sep 30: > John-Mark Gurney wrote: > > > the reason I was on Marcel's back was because of his statement that he > > WOULD NOT do ANYTHING to fix the problem, and that as far as he was > > considered, that's life and deal w/ it... if he had said, oh, I'll look > > for a solution to the problem, I wouldn't of been so hard on him... > > I said that for the -current case. I also said that an upgrade from > -stable to -current will be fixed if it was broken. you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... the make buildworld -DNOTOOLS does not work, and will not work for what I like to do.. I need tools from -current that RUN ON -stable... you completely cut the whole part of me agreeing w/ Peter about -DACIENTTOOLS... 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: ===> libgcc echo '#include <i386/xm-i386.h>' > config.h echo '#include <xm-freebsd.h>' >> 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' *** Error code 1 it took me all of 21 minutes for the buildworld to fail.. considering I'm not running softupdates, it'd be even faster... > > so, is Marcel going to do the work for this? or will this have to be > > passed to someone like you or myself? > > I'm not going to claim this. Everyone with a constructive opinions can > join the club. It's so much easier for everyone if it's done by more > than 1 person. Those that don't feel confortable solving this problem > are encouraged to test solutions. so, I take this that you are uninterested in trying to solve the problem at hand? I vote for Peter's idea, which is something that I was thinking about before he sent the idea out... just in a different way... > As for me, I'm trying to define the problem as detailed and consise as > possible. I already have some specific thoughts and ideas. I'm thinking > large here: real cross-compilation capabilities and such (it may be > handy for FreeBSD/IA64)... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990930163945.56976>