GCC: are -static and -pie incompatible for x86?

I will recompile some executable file for Android 5.0, since it requires that the executables be PIE . I managed to recompile it for ARM by simply adding some arguments when configuring (with standalone toolchain):

 export CFLAGS="-I/softdev/arm-libs/include -fPIE" export CPPLAGS="$CPPFLAGS -fPIE" export CXXLAGS="$CXXFLAGS -fPIE" export LDFLAGS="-L/softdev/arm-libs/lib -static -fPIE -pie" 

Error for ARM:

 configure:3406: arm-linux-androideabi-gcc -o conftest -I/softdev/arm-libs/include -fPIE -L/softdev/arm-libs/lib -static -fPIE -pie conftest.c >&5 configure:3410: $? = 0 

But I could not do the same for x86 , as I get the error:

 export CFLAGS="-I/softdev/x86-libs/include -fPIE" export CPPLAGS="$CPPFLAGS -fPIE" export CXXLAGS="$CXXFLAGS -fPIE" export LDFLAGS="-L/softdev/x86-libs/lib -static -fPIE -pie" 

Mistake:

 configure:3336: i686-linux-android-gcc -I/softdev/x86-libs/include -fPIE -L/softdev/x86-libs/lib -static -fPIE -pie conftest.c >&5 /softdev/x86-toolchain-gcc4.8/bin/../lib/gcc/i686-linux-android/4.8/../../../../i686-linux-android/bin/ld: fatal error: -pie and -static are incompatible collect2: error: ld returned 1 exit status configure:3340: $? = 1 

I need the executable files to be linked statically. What is wrong and how can I fix it?

PS. Also tried using standalone x86 toolchain from android ndk r9d and r10c:

 ./make-standalone-toolchain.sh --toolchain=x86-4.8 --arch=x86 --install-dir=/softdev/x86-toolchain-gcc4.8-r9d --ndk-dir=/softdev/android-ndk-r9d/ --system=darwin-x86_64 
+6
gcc android-5.0-lollipop
Nov 22 '14 at 21:50
source share
3 answers

I just did a quick test using te.c:

 int main( int argc, const char* argv[] ) { return 0; } 

Running arm-linux-androideabi-gcc -o conftest -static -FPIE -pie te.c does not cause errors. However file -k conftest prints

 conftest: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), not stripped 

readelf -l conftest outputs File type Elf - DYN (shared object file) Entry point 0x500 There are 7 program headers starting at offset 52

 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00000034 0x00000034 0x000e0 0x000e0 R 0x4 INTERP 0x000114 0x00000114 0x00000114 0x00013 0x00013 R 0x1 [Requesting program interpreter: /system/bin/linker] ... 

The presence of PHDR and INTERP headers indicates that -pie silently overrides -static in the hand compiler. Why I do not know this, but I would consider it a mistake that does not give a warning when -static and -pie are used together. Instead of programmers like you, the false impression is that these two options can be used together on the hand.

Just to clarify the only behavioral difference here is that x86 compiler errors when viewed as -static and -pie, while the arm version silently ignores -static if --pie. If only one is specified, the behavior is the same for both compilers.

+4
Feb 01 '15 at 3:55
source share

If -pie and -static are both specified together, gcc will throw an unexpected error.

-pie

Create an independent position for goals that support it. For predictable results, you must also specify the same set of parameters that are used for compilation (-fpie, -fPIE or the model subsystem) when you specify this linker option.

-pie actually creates a DEF file of type DYN with INTERP with / system / bin / linker

executable compiled with -pie

-static

On systems that support dynamic linking, this prevents linking to shared libraries. On other systems, this parameter has no effect.

-statically create an exec file type without INTERP

0
Jul 29 '16 at 7:27
source share

The Google NDK tool contains some information about using PIE. Visit build / core / build-binary.mk , see line 209. It says:

# enable PIE for executable file beyond a certain API level, unless "-static"

I assume this is a limitation on linux dynamic link. Since the Android interpreter (/ system / bin / linker), which determines which address an elf file should be loaded into a static linked file, does not have an interpreter, the elf file will be mapped to a fixed address in the linux kernel. This change is discussed here by Google issue

If I have a mistake, please find out :)

-one
Mar 20 '15 at 7:34
source share



All Articles