Date: Fri, 01 Oct 1999 09:02:36 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed Message-ID: <37F45C8C.D3ED77F9@scc.nl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37F45C8C.D3ED77F9>