don't exist as compat functions in libc.
current list of new platforms: powerpc64.
from dennis.c.ferguson@gmail.com in PR#43042. idea to not put compat
functions into new platforms from drochner@netbsd.
it is not usual case(merely used such mutibyte locale, eg. ja_JP.ISO-2022-JP).
[background]
before merging minoura-xpg4dl branch(2001), we argued and decided to increase
MB_LEN_MAX 1 -> 32 all CPUARCH(*but* we forgot to change it MD to MI).
without knowing that NetBSD/hp700(mergeing -current 2002) incorrectly set
MB_LEN_MAX=6 (maybe this value taken from FreeBSD). but our setlocale(3)
assumes __mb_len_max_runtime as 32, so that mbrtowc/wcrtomb may overrun.
we have to increase hppa's MB_LEN_MAX upto 32, and change it MD to MI
next libc major bump(scheduled next release 6.0).
libc implementation (such as *BSD and glibc2).
2. don't typedef void * wc{type,trans}_t, suggested by soda@-san.
it may pass through compiler type check, it's harmful.
so i introduce dummy struct __tag_wc{type,trans}_t(iconv_t already does).
no ABI change was made.
patch provided by tshiozak@ -san.
2. don't eat 0xfeff/0xfffe if they don't appear at the first of bytestream.
noticed y tshiozak@ -san, patch provied by me.
thanks a lot.
most of them are most harmless, but the libgcc parts are quite essential.
before this change, all the special rules for .pico files were not applied,
and exception handling wasn't enabled. this caused c++ exceptions not to
work on sparc64.
this fixes the build of boost-headers (it was correctly calling exception
support broken!), which in turn makes all the things that depend upon it
to actually work again on sparc64.
While kernel source code is supposed to use <machine/macros.h> via
<sys/param.h> and pick an inline asm version from there, gcc itself
can generate direct calls to memset() for structure initialization, so
the symbol must be provided.
Fixes INSTALL kernel, for which -Os caused gcc to use memset() call to
initialize a struct in uvm_fault_internal().
mfs uses the mounting process for the backing store memory. I
guess mfs could be fixed to just reference the process vmspace and
let it return, but that would probably cause wait() to return for
other worms. So it's easier to dance according to mfs's tune: if
mounting mfs, create a thread for extra execution context.