On Wed, 17 Oct 2001, James Chacon wrote:

: >: So what I'm proposing is a new define HOST_TOOLCHAIN that is used to null out
: >: sections like this (and accordingly have the tools/Makefile's set it within
: >: CPPFLAGS for all builds). Doing this was relatively simple on runetype.h.

: >The include file needs to be *duplicated* (with appropriately bit-sized
: >types in the structs) and put in with the mklocale sources so that the
: >entire mklocale program can be used independently on a non-NetBSD host.

: That introduces a maintaince nightmare. The whole point of reachovers in
: the current system is to avoid duplicating over and over the same code when
: it can be used in different places fairly easily like this.

Reachovers are fine, and reachovers are in fact used by src/tools.  However,
reachovers are used for the sources of programs -- we cannot pull in a
header file from a library that will only be built for the target system,
even if it's #ifdef'd all over.

When talking about cross-compiling, host and target tools should ideally be
considered to be entirely separate entities, particularly in cases where
binary output files are created.  A host tool should assume that the host
system has unknown sized "int" and "long" and signedness of "char", and
unknown endianness.  The ABI should be as explicitly defined as possible in
the host tool, so no host compiler dependencies will trigger the Wrong Thing
at build time.

: Currently *nothing* in the tools area meets your definition for cross
: compiling. Everything includes netbsd specific include files, netbsd defines,
: etc.

Yes, this is one of the items I've mentioned and am working on now.  At the
moment, in fact, much of the tools and system builds for me on a Cygwin(!)
host.  I'm committing these changes as they are stabilized.

: How would you handle something like mtree which includes all sorts of support
: for the file flags?

There is a separate project being worked on by another person right now to
permit holding back permissions and flags at build time, so you could build
the system as an unprivileged user, and have the permissions added
on-the-fly to the resultant tarballs.  As well as a project to make ffs
filesystems for install media on a non-NetBSD host.

In summary:  we are currently in the process of making the build tools run
on non-NetBSD hosts.  Since mklocale doesn't even compile on 1.5.x, it has
not been moved into src/tools yet even as a half-done effort.  Because of
how interwoven mklocale is with libc's rune header files, until it is
separated and made to cross-compile properly, mklocale should remain
disabled by default.

: >: Finally, the really ugly part...When you create a new locale the invalid rune
: >: gets set to the INVALID_RUNE macro as the default. This macro though is just a
: >: reference to _CurrentLocale which of course isn't a symbol present in anything
: >: except -current. (Why the invalid rune for a new locale should default to
: >: different values depending on ones current locale while using mklocale is
: >: beyond me, but I'm not going there...)

: >: Just set this value (via a netbsd version check) to -3 (which is what it
: >: defaults to in the end libc code)
: >
: >This is the correct choice,

: Which is exactly the opposite of how it works "natively".

The "native" behavior should be changed as well.  Depending on any user's
external settings for building a static file is wrong.  INVALID_RUNE must be
a constant when building a rune table.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/