Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas <rockyhotas%post.com@localhost>]

For some reason, my messages are not delivered to this ML. I try to
merge them into a single reply both for Martin and Valery, from another
address. I apologize for any inconvenience and/or double messages you
may have received.


Part 1

On mag 05 13:21, Martin Husemann wrote:

> No, but you may have the choice wich kernel/userland you want to run
> on the same physical hardware. An example is my cubietruck:
> I run it big-endian as:
>
> [~] martin@space-truckin > uname -p -m
> evbarm earmv7hfeb
>
> but most people use exactly the same hardware to run earmv7hf (little endian)
> instead.
>
> On this board the difference is a simple "set endianess" instruction early
> in the kernel, but on some other machines it is a physical jumper on the board.
>
> This is not a very typical case though.

It's the first time I "hear" (actually, read) about it. It offers
great flexibility!

> The "compat" cases are more common: on arm machines you can execute
> binaries for eabi (the default) and oabi. On aarch64 machines you could
> run aarch64 (native 64bit), eabi (new 32bit abi) or oabi (old 32bit abi).

This way, MACHINE seems to represent the entirety of the hardware
devices which compose a specific system. It doesn't (it can't!)
change, of course.  Then, given this "static" hardware, you may make some
choices about endianness (as in the cubietruck example) and/or ABI (as
in this compat example) and/or some other features: this determines
the architecture, the instruction set you choose to build the kernel
for (the instruction set you choose to run on the actual CPU), and
this architecture is exactly MACHINE_ARCH.

> I guess now you see the complex spread sheet and understand why you have
> been confused initally - hope it got better during this thread ;-)

Oh, I think (I hope!) yes, it's becoming to be more clear, I really
couldn't figure it out before.

Thank you so much :)


Part 2

On mag 05 15:34, Valery Ushakov wrote:

> Yes.  It's just formatted using mdoc, but is not installed as part of
> system manual pages.

Ok! This is what produced that header.

> I think Martin explained it pretty well in another followup.

Yes, it was very useful :)

> If by the "directory tools" you mean the one in the build directory
> (it took me a while to realize that), then yes.  It's called an objdir
> and is a standard make(1) feature.  Please check make(1).

Sorry, it was not clear. Assume that you run, on a NetBSD 9.99.81 amd64
host system,

./build.sh -U -O ~/obj -j2 -m evbarm -a aarch64 tools

(as in par. 32.1 of The NetBSD Guide)

then you will have, in ~/obj, two subdirectories:

tooldir.NetBSD-9.99.81-amd64
tools

By "directory tools" I was meaning the last one listed above,
`~/obj/tools'. I hope that ~/obj is in this case what you mean by
"build directory".

As regards ~/obj/tools and running make(1) in this directory,

     .OBJDIR         A path to the directory where the targets are built.

Now I understand why you wrote ``tools is the objdir for the
src/tools, a place where tools are built'' in the previous message.

> Yes, we build our own make, sed, etc as part of the tools build and
> install them in $TOOLDIR/bin.  We add nb- prefix to the installed
> versions to avoid name clashes with the host programs.  E.g. GNU
> programs (can) do the same, using g- prefix (and in some cases that g-
> even fused into the name (gcc, gawk)).

Oh, amazing! And I guess `nb' stand for `(N)et(B)SD'.

Thank you so much,

Rocky