Date: Thu, 30 Sep 1999 17:32:29 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Nate Williams <nate@mt.sri.com> Cc: Marcel Moolenaar <marcel@scc.nl>, Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed Message-ID: <19990930173229.61526@hydrogen.fircrest.net> In-Reply-To: <199909302344.RAA01090@mt.sri.com>; from Nate Williams on Thu, Sep 30, 1999 at 05:44:25PM -0600 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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'
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990930173229.61526>