On Tue, Aug 16, 2016 at 2:22 PM, Rob Landley <r...@landley.net> wrote: > > On 08/16/2016 04:04 PM, enh wrote: > > looking at the bug, i can cut a long story short for you: cutils isn't > > an NDK library, and you don't have a new enough NDK to have <pty.h>. > > (there are also going to be a ton of other problems hidden behind those.) > > > > the bad news is that NDK r13 won't have <pty.h> either --- we slipped > > the unified headers to r14 yesterday, sadly, because although we do have > > headers, we haven't got enough of the build system support done, and we > > don't want to hold up the release (which includes independently useful > > stuff such as an updated libc++ and the new command-line cpu profiler). > > > > https://github.com/android-ndk/ndk/issues/120 is the bug covering the > > unified headers work, though the action is all in AOSP so that bug > > doesn't show you the changes as they go in. > > > > anyway, yeah, the NDK headers are about three years behind the platform. > > (fun fact: the N and M headers are actually just the L headers, and the > > L headers aren't actually the platform L headers either.) until we > > finish fixing that mess, you're just wasting your time and polluting > > your code. > > > > if you want to run on a modern device, build out of an appropriate AOSP > > tree. if you want to run on an old device, build statically out of a > > modern AOSP tree. > > I have a machine I can clear 200 gigs off of, but it's not the netbook I > have with me most of the time. Is there any way I can build and then > _export_ a toolchain from AOSP?
i wasn't kidding when i said that making the NDK headers sane is a work in progress :-) here's a patch from 4 hours ago: https://android-review.googlesource.com/#/c/256800/ historically the NDK headers were a _fork_ of the bionic headers. we're working on unforking, and working on making it so that no matter which version of android you're targeting (gingerbread, say), you're still using up-to-date headers; they'll just not make available stuff that wasn't in gingerbread. (if you're using clang, you'll even get error messages explicitly telling you "f was introduced in jellybean but you're targeting gingerbread" rather than just "implicit declaration of f" or whatever.) so there's no existing "update the headers" process/scripts, just the stuff we're working on right now. > Presumably the NDK comes from somewhere... yeah, it's just another manifest (master-ndk rather than master) in AOSP. instructions to build it here: https://github.com/android-ndk/ndk but like i said, it's not that we have a fixed NDK and just haven't shipped it yet --- we're still working on fixing the headers. but getting back to your intent... it's a pain in the ass, but if you have an AOSP build and an unpacked NDK (or an NDK you built yourself; doesn't matter), you can copy the libc.so and libc.a out of out/, and you can cp -r the headers out of bionic/. the awkward part with the latter is flattening the uapi headers. in the platform they're kept nice and separate (and per-arch), but in the NDK they end up all collapsed into a regular sysroot. alternatively (though i've never done this), i don't see why you couldn't point your NDK compiler at the relevant lib and include directories in the platform. but the easiest for those with enough disk space... if you check out an AOSP tree, change the external/toybox/Android.mk to say "LOCAL_FORCE_STATIC_EXECUTABLE := true" and then mma -j in that directory, that should leave you with a tree with just enough built. i guess you might be able to then prune away enough unused stuff (device/, hardware/, vendor/, frameworks/, art/, and so on) to transplant that onto a smaller disk. > Thanks, > > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
