From owner-freebsd-current Fri Oct 1 0: 2:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 8057D14D44 for ; Fri, 1 Oct 1999 00:02:44 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.02 #1) id 11WwiI-0005rg-00; Fri, 1 Oct 1999 07:02:42 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id JAA29848; Fri, 1 Oct 1999 09:02:36 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37F45C8C.D3ED77F9@scc.nl> Date: Fri, 01 Oct 1999 09:02:36 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney Cc: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John-Mark Gurney wrote: > > 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... I do understand. You would have known if you followed the other threads on this topic. > 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: I haven't had time to read is suggestion, contemplate and determine its strengths and weaknesses for myself. If everybody stopped whining for a minute ;-) > ===> 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' > *** Error code 1 Mine has stopped at exactly the same point. I started a make world yesterday (it finished tonight). > it took me all of 21 minutes for the buildworld to fail.. considering > I'm not running softupdates, it'd be even faster... Congratulations! > > 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 Yes. This can't be done. > 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.. We have never supported running -current binaries (ie compiled against a -current environment) to run on -stable. If it worked in the past, nice. > 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... No that's not the real problem here. You're redefining the problem to match your solution. > 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... No, we don't have a catch-22. We're using the wrong sources for the wrong reasons. > 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... That may solve this problem, but doesn't leave you with cross-compilation. > 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... I can't parse this. The old sisgnal code hasn't been removed. We have to explicitly add support, because we need to transform the new sigset_t related calls onto the old. > 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... What you are saying, is that libc must be used as a compatibility shell, right? > and as Bruce will point out... the fact that -current's libc even builds > on -stable and has run is completely by chance... Exactly. So are running binaries. > 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... Exactly. This has been discussed in another thread with Rodney. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message