When writing makefiles or using automake and friends, its currently not possible to to supply 'generic' set of flags via CFLAGS (or CXXFLAGS) and produce position independent code and utilize layout randomization. For example the following will properly setup makefiles for programs, but not shared objects: $ configure CFLAGS="-Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" Others have also felt the discomfort: http://lists.fedoraproject.org/pipermail/devel-announce/2011-August/000821.html. Please provide a switch that allows us to use position independent code and layout randomization that works on both programs and shared objects. I suggest the switch "-aslr" or "-ASLR".
I think this is wrong approach to things. Basically you should have instead have an option to automake and friends the support for adding only some flags for non shared libraries. Also using -fPIC instead of -fPIE is always ok. So I doubt there is a really issue here. Since the differences between PIC and PIE comes down to if symbols are overridable. PIC is conservative at optimizing. Also how can you tell the difference between compiling for executable and shared library if you don't supply -fPIC? So adding -aslr is not going to be useful really.
GCC is not a mind reader. There is no way for GCC to know if you want to do PIC or PIE code.
(In reply to comment #2) > GCC is not a mind reader. I kind of knew that. > There is no way for GCC to know if you want to do > PIC or PIE code. Forgive my ignorance, but why does it matter at the code generation stage? How are relocations different in the object code of a program versus a shared object? At code generation, I did not think there was even the concept of program or shared object.
(In reply to comment #1) > > Also how can you tell the difference between compiling for executable and > shared library if you don't supply -fPIC? So adding -aslr is not going to be > useful really. The compiler driver would make the determination at link time, and pass the appropriate switch to the linker. I did not think it was a difficult concept. My apologies.
>Forgive my ignorance, but why does it matter at the code generation stage? Easy. With PIE, global variables and functions are considered to bind local while with PIC they are considered to bind globally (aka override able). >At code generation, I did not think there was even the concept of program or shared object. And this is where you are wrong. GCC has a concept of program vs shared library.
(In reply to comment #5) > >At code generation, I did not think there was even the concept of program or shared object. > > And this is where you are wrong. GCC has a concept of program vs shared > library. My apologies. I was not aware that object code had a gender (program versus shared object).
(In reply to comment #1) > Also using -fPIC instead of -fPIE is always ok. So I doubt there is a really > issue here. Since the differences between PIC and PIE comes down to if symbols > are overridable. PIC is conservative at optimizing. -fPIC/-pic apparently breaks other GNU tools: ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC -pic -Wno-unused-parameter -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/home/jeffrey/sipwitch-1.3.1': configure: error: C compiler cannot create executables See `config.log' for more details