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:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
