On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote:
> The problem
> -----------
> When doing a make world, tools are being built that are used by the
> build process. This is to make sure that the tools are appropriate for
> doing a make world. The problem we now face is that the sigset_t change
> causes this to break. The tools that are being built use new syscalls
> not present in a kernel. Not only that, the new tools expect a different
> sigframe in general.
As far as I can see, if this is the case, then this is the only
problem. The tools built for a buildworld are tools that have
to run on the _current_ platform, whatever that might be, with
the new platform as a target. Therefore, they should be build
against the existing system include files and libraries, and so
should run on the existing system.
With these tools, we build the world.
As far as I can tell, the problem is installworld.
Either:
(a) The tools required to build the corresponding new kernel have to
be secreted away in an "upgrade-bin" directory, so that they are
still accessible after the install world (none of which will run
on the existing kernel).
(b) You build a new kernel before you do the install-world,
reboot, and then installworld.
I can't see any bennefit at all to (a), or any problem with (b).
As I mentioned in a previous mail, why on earth should we expect
user-land programs built to a new API to run on a kernel that
doesn't support that API. The converse has always been true,
though. Kernels usually support any new API and the previous one
or more, so that old applications will still run.
That said, I don't mind your idea of extending the stable
kernel, but that is still really just a sneaky way of getting
the user to build and install a kernel that supports the new API
before they try to installworld. Isn't it?
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
