This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Error Building GCC as PIE
- From: Cyd Haselton <chaselton at gmail dot com>
- To: noloader at gmail dot com
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Mon, 22 Jun 2015 04:36:39 -0500
- Subject: Re: Error Building GCC as PIE
- Authentication-results: sourceware.org; auth=none
- References: <36F38A10-BFB2-40DE-BD89-34C243C43B9C at gmail dot com> <4BA77817-731F-4D4F-AC88-5606D1615D50 at gmail dot com> <3F3CD0D0-9A01-46BC-8A53-FF4A0E400696 at gmail dot com> <CAH8yC8mC7D13uF1Pt2MyS9jv_u1VOqqVHiDLCv6cL8O41O_HiQ at mail dot gmail dot com> <CAH8yC8mxt59GkLhrQX-qKyT5RafD9AnXbFCq9RUzVABW+4syCg at mail dot gmail dot com>
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@gmail.com> 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@gmail.com>
>wrote:
>> On Fri, Jun 19, 2015 at 1:23 PM, Cyd Haselton <chaselton@gmail.com>
>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.
>>