>
>On Wed, 17 Oct 2001, James Chacon wrote:
>
>: Ok, so I don't use HOST_TOOLCHAIN..I could use MAKE_BOOTSTRAP since that's
>: the convention make/config already use. In any case ifdef'ing out sections
>: of code so pieces of this build on foreign platforms is exactly the convention
>: already in place. I just used a different define here to make it obvious what's
>: going on. Neither file I've touched in this way has any external scope into
>: userland directly (i.e. runetype.h doesn't get installed into /usr/include).
>
>In the case of mklocale, it really shouldn't be this difficult.  A program
>properly written to use a static ABI regardless of host is the goal.  That
>implies detaching from the internal libc headers, and making mklocale its
>own self-contained entity, but should in the process *simplify* its code.

Ok, we're both in agreement here :-)

Hmm....I could split runetype.h into 2 files and provide one as an exposed
one to /usr/include which just contains the locale and file locale structs.
But, these are tied together with libc and there's no way around that...

The libc routines need the same structs to read the binary data back from the
files. Nothing else except mklocale really needs this information since the
binary files are essentially opaque types otherwise. Keeping separate includes
(one locally in mklocale) makes no sense since changes would cause divergence.

I'm open to ideas here but "rewrite mklocale to not use the libc stuff" isn't
gonna work. They are tied together and other programs do thing similarly when
needed (at first pass setkey in sbin pulls in includes from libipsec for
instance).

James