Ok, libkvm will be available now if you pull (*) and rebuild. I tested
kvm to work per how uwsgi uses it, though the process info returned will
not reflect full reality: since there is no virtual memory in a rump
kernel, the rump kernel does not really know what the virtual size of a
process is. But at least the build should work now.
*) NOTE: if you pull to an already-built rumprun repo, you must do a
"git submodule update" after you pull rumprun. The build script updates
the submodules automatically but only if they don't already exist.
(I'll admit that's a bit against POLA, so if someone has better ideas on
how to handle things, I'm all ears).
Also, some notes on looking at what uwsgiconfig.py does:
* it uses python os.uname() to determine the target OS, which of course
does not produce a xcompile-pertinent result. hardcoding that uname call
result to NetBSD makes things go a bit smoother
* runs $CPP. our current rumprun toolchain does not provide cpp even
though buildrump.sh generates a wrapper. However, the buildrump.sh
wrapper uses $CC -E as cpp. uwsgi wants to run "$CPP -v" to figure out
include paths. Maybe we'll just add a real cpp when we finalize the
rumprun crosscompile toolchain.
* hardcodes library probe paths to /usr/lib. that obviously goes wrong
when you're cross-compiling.
So, in short, we need to improve a bit (cpp), but that software isn't
even pretending to support cross-compilation, and hence the majority of
the troubles observed.
