At this point...after researching/working on this for most of the weekend i'm not sure if I should be cross-compiling or not. I'm leaning towards "should"...as there's been some changes to android's libc...but I've been unable to get past configuring binutils; I've run into this "present but cannot be compiled" error regardless of what I do: checking sys/resource.h presence... yes configure: WARNING: sys/resource.h: present but cannot be compiled configure: WARNING: sys/resource.h: check for missing prerequisite headers? configure: WARNING: sys/resource.h: see the Autoconf documentation configure: WARNING: sys/resource.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/resource.h: proceeding with the compiler's result checking for sys/resource.h... no looking for a compliant stdint.h in stdint.h, checking for uintmax_t... no looking for a compliant stdint.h in inttypes.h, checking for uintmax_t... no looking for a compliant stdint.h in sys/inttypes.h, checking for uintmax_t... no looking for an incomplete stdint.h in stdint.h, checking for uint32_t... no looking for an incomplete stdint.h in inttypes.h, checking for uint32_t... no looking for an incomplete stdint.h in sys/inttypes.h, checking for uint32_t... no looking for u_intXX_t types in sys/types.h, checking for u_int32_t... no looking for u_intXX_t types in inttypes.h, checking for u_int32_t... no looking for u_intXX_t types in sys/inttypes.h, checking for u_int32_t... no checking what to include in bfd_stdint.h... stddef.h (using manual detection) checking size of void *... (cached) 0 checking size of long... (cached) 0 checking size of int... 0 checking size of short... 0 checking size of char... 0 checking for type equivalent to int8_t... configure: error: no 8-bit type, please report a bug make[1]: *** [configure-bfd] Error 1 I fear I've broken something in my sysroot On June 21, 2015 10:42:43 PM CDT, Jeffrey Walton <noloader@xxxxxxxxx> wrote: >>> While researching how to cross-compile for PIE, I discovered my >theory was based on a faulty premise: that PIE binaries will only run >on Android 5.0. > >My bad... I parsed this wrong the first time.... > >PIE was introduced in Android 4.1. From "Security Enhancements in >Android 1.5 through 4.1" >(https://source.android.com/devices/tech/security/enhancements/enhancements41.html): > > Android 4.1 > > PIE (Position Independent Executable) support > ... > >If you try and run a PIE binary on Android 4.0 or below, the the AOSP >link/loader will crash. It will segfault in /system/bin/linker. See, >for example, http://stackoverflow.com/q/8484814. > >I was told the solution is to provide a custom loader, but I never >pursued it. > >Jeff > >On Sun, Jun 21, 2015 at 11:36 PM, Jeffrey Walton <noloader@xxxxxxxxx> >wrote: >> On Fri, Jun 19, 2015 at 1:23 PM, Cyd Haselton <chaselton@xxxxxxxxx> >wrote: >>> While researching how to cross-compile for PIE, I discovered my >theory was based on a faulty premise: that PIE binaries will only run >on Android 5.0. >>> >> >> As far as I know, this is true. Android 5.0 requires PIE. From >> "Security Enhancements in Android 5.0" >> >(https://source.android.com/devices/tech/security/enhancements/enhancements50.html): >> >> Non-PIE linker support removed. Android now requires all >> dynamically linked executables to support PIE (position >> independent executables). This enhances Android’s address >> space layout randomization (ASLR) implementation. >>
