We're still seeing lots of confusion. People do seem to look as far as
the headers, but stop there. So let's try a bit harder to point them in
the right direction.
Also explicitly state that removing _FILE_OFFSET_BITS=64 is the
behavior-preserving fix for compilation problems when upgrading to NDK
r15 or later.
Bug: N/A
Test: N/A
Change-Id: I2d5c65b2fb5cccb9977901e51fea1ad2ccc0fd95
This reverts commit 9af9120091 (a revert
of 079bff4fa5), now the versioner bug is
fixed.
Bug: http://b/64613623 # header bug
Bug: http://b/64802958 # versioner bug
Change-Id: I1cb9d7832d4b3aecdc57a9285e2291443e59d02d
This reverts commit 079bff4fa5.
Broke builds with SANITIZE_HOST=address with an asan failure in versioner.
Change-Id: I22b113fd5405589d1a25e5e137c450aaba1ade5f
We had several bugs filed saying "if I set _FILE_OFFSET_BITS=64 when
targeting an API < L, various functions are missing". Instead of
saying "yes, they are", we quietly just modified the header files to
expose the non-64-bit variants. This makes no sense. We can't just say
"oh, yeah, we don't have a version of this function that agrees with
your calling code about how large off_t is, but here's a version that
doesn't: I'm sure it'll be fine".
_FILE_OFFSET_BITS=64 on Android LP32 has always been a game of chance,
but that game should be "are all the functions my code needs available
at compile time?", not "will my code actually work at run time?".
Bug: https://github.com/android-ndk/ndk/issues/449
Bug: https://github.com/android-ndk/ndk/issues/442
Bug: https://github.com/android-ndk/ndk/issues/333
Bug: https://github.com/android-ndk/ndk/issues/332
Bug: https://github.com/android-ndk/ndk/issues/324
Test: builds
Change-Id: Ib095251d3e21e77ed50cc3575388107fecec4ecd
Without this, setting __FILE_OFFSET_BITS to 64 and targeting pre-L
made sendfile entirely unavailable.
Bug: https://github.com/android-ndk/ndk/issues/333
Test: builds
Change-Id: I82d326ff244473dd5443632ff6c19d726d5e29ee
I still don't think we can make stdio's fseeko and ftello work, but we can
have everything else, and very few programs use fseeko/ftello (and they can
just refrain from using _FILE_OFFSET_BITS and be no worse off than they are
today).
Bug: 11865851
Change-Id: Ic3cb409aae6713f4b345de954bcc4241fcd969ec
