The build used the host ar instead of the cross ar. With -mbig-obj as
the default (c9c9c073), the host ar cannot understand the PE32 object
files and so doesn't produce a symbol index. Not the first time this
problem has come up.
This static library provides memset, memcpy, memmove, memcmp, and
strlen. The implementations are minimal wrappers around x86 string
instructions, making them both tiny (~26 bytes apiece) and reasonably
performant, though not nearly as fast as CRT implementations. I selected
these particular functions because GCC fabricates calls to each out of
thin air at some optimization levels. The first four are also genuinely
useful as built-ins (__builtin_memset, etc.), keeping in mind arbitrary
limitations with null.
Mingw-w64 does not implement them but instead offers imports from system
DLLs: -lmsvcrt, -lmsvcr120, -lucrt, -lntdllcrt. It creates a dependency
on a system DLL: practical, though unoptimal, and no licensing woes.
With -nostartfiles instead of -nostdlib, this happens implicitly.
MSVC provides static definitions in libvcuntime.lib, useful when cl or
clang-cl fabricates calls. They weigh several KB each, and require the
application or installer to present a EULA ("external end users to agree
to terms"). Not a great trade-off just for some basic memory functions.
In w64devkit, libmemory fills this role. It's a public domain library so
there are no license terms. Just add -lmemory to the build command. It
also allows liberal use of the associated built-ins, especially in debug
builds, which can benefit from fast memory operations despite -O0. MSVC
toolchains can also freely use libmemory.a, though it won't know how to
find it without help of course.
I do not plan to add more functions except for cases of GCC fabricating
calls (e.g. strlen). Certainly no null-terminated string functions.
