On Mon, Sep 3, 2018 at 9:32 AM Rob Landley <[email protected]> wrote: > > On 08/31/2018 07:10 PM, Ryan Prichard wrote: > > FWIW: the NDK version is available in these files: > > - source.properties > > - sysroot/usr/include/android/ndk-version.h > > There's no source.properites under the install but there is an ndk-version.h > with 17.0.1 in it. Good to know, thanks. > > > 2) I applied the attached patch, some bits of which should get merged > > and others > > I dunno about. (The structure ping wanted... did that git fixed upstream > > already?) > > > > It looks like there's a struct icmphdr in the NDK's UAPI header > > linux/icmp.h. > > That header isn't usable on my glibc system because it conflicts with the > > glibc > > netinet/ip_icmp.h header, but maybe it's OK to use with the NDK, though? > > I hit that conflict too. The problem is being ok to use with the NDK _now_ > doesn't mean it won't add its own later and then hit the same conflict. > (That's > why I put the local copy of the structucture definition under a new name in my > patch; ugly but avoids the conflict.)
no need to worry. when i added the struct, i added the corresponding unit test that it's visible when you include <netinet/ip_icmp.h>, so we can't regress the user-visible part even if the exact location of the struct changes. commit e5a5eec5e588957aba2582ef25795bb3b573669f Author: Elliott Hughes <[email protected]> Date: Wed Jun 27 12:29:06 2018 -0700 <netinet/ip_icmp.h>: ensure struct icmphdr is available. Needed to build toybox ping. Bug: N/A Test: ran tests Change-Id: Ifd0f0ccbb8351c6a0ece526b050778fd02e984bf > What I'd like to do is get to the point where defconfig builds under the NDK > (switching off the appropriate commands as necessary in the compile-time > probes), and then regression test both ways (new NDK release and new toybox > release) as part of my quarterly release prep. > > Another thing I'd like to do is have new (static) toybox binaries I can > download > and use on old android releases. I was doing that with musl-cross-make but > bionic/llvm would be better. (They're _still_ selling Android K tablets at the > grocery store, and my Nexus 5 got upgraded to M a year after I bought it but > hasn't even had a bugfix release since 2016.) I'm aware stuff like ps wouldn't > have the selinux annotations to work right and things like the logger bindings > aren't available in the NDK, but for things like sed... > > Except support for 32 bit's being dropped at some point and I dunno the > schedule > of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An > android version of lwn.net maybe? roadmap: https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md release notes (which tend to include forward-looking announcements): https://developer.android.com/ndk/downloads/revision_history but, no, 32-bit isn't going anywhere any time soon. we *are* insisting that folks have a 64-bit version of any 32-bit app so that at some point it'll be possible to have a 64-bit-only device, but i assume even that will only be another step in the slow decline of 32-bit. (and remember that the NDK effectively has to worry about ~5-year old devices, so even if you weren't allowed to ship a 32-bit P device [which isn't true --- you totally can] it would still be ~2023 before we could consider dropping 32-bit from the NDK [assuming that device lifespan stays roughly where it currently is].) > Rob > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
