On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote:
> On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote:
> >Before attempting to build world, you must make and install a new
> >kernel. The new kernel will contain new syscalls that are needed during
> >build world. doscmd is currently not being build because it needs fixing
> >first.
>
> I'd like to voice my concerns with this change as well. The `normal'
> upgrade procedure has always been to build and install a new world
> before the new kernel. The only exception I'm aware of has been the
> aout->elf transition (where a special build procedure was provided).
Isn't this backwards? The kernel's the place that can (and
must) have the backwards-compatability hooks, for the simple
reason that even if you build the world, your ports and
third-party applications have to keep running. Kernels are
built and updated without corresponding buildworlds all the
time.
If you change something fairly fundamental about the interface
specification for the userland-kernel interaction (say, going to
64-bit file offsets, for an equivelant example), then it seems
pretty obvious to me that a program or library compiled to the
new spec _cannot_ run on a kernel that doesn't implement it.
How could it be otherwise?
This seems to be a different argument to the one John-Mark is
makeing: he isn't trying to _run_ his new world on his old
kernel, just compile it. I agree that there are probably some
curly issues regarding building a build-only set of tools.
These are obviously going to be _different_ from the equivelant
tools that you want built as part of the buildworld, being
cross-compilers and so on. I don't know how close the build
target is to that ideal.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
