module-init-tools gives additional -fPIC errors on amd64 with -pie in LDFLAGS. gcc -O2 -fomit-frame-pointer -pipe -fstack-protector -o insmod insmod.o insmod_64.o kallsyms_64.o rmmod.o modprobe.o lsmod.o ksyms.o kallsyms.o ../obj/libobj.a ../util/libutil.a -pie -Wl,-Bstatic -Wl,-Bdynamic /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: insmod.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC insmod.o: could not read symbols: Bad value temp fix, filter-ldflags -pie, long-term, *shrug* i'm working on it
even without pie, i came across another error while messing with hardened: gcc -O2 -fomit-frame-pointer -pipe -fstack-protector -Wunused -Wall -o lsmod lsmod.o -Wl,-Bstatic -lz -Wl,-Bdynamic /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../libc.a(ssp.o)(.bss+0x0): multiple definition of `__guard' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libgcc.a(_stack_smash_handler.oS)(.bss+0x0):/var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/gcc/libgcc2.c:2219: first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../libc.a(ssp.o)(.text+0x90): In function `__stack_smash_handler': : multiple definition of `__stack_smash_handler' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libgcc.a(_stack_smash_handler.oS)(.text+0x90):/var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/gcc/libgcc2.c:2234: first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: Warning: size of symbol `__stack_smash_handler' changed from 640 in /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libgcc.a(_stack_smash_handler.oS) to 571 in /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libgcc.a(_stack_smash_handler.oS) collect2: ld returned 1 exit status make: *** [insmod.static] Error 1 wth?
Travis, hrmm.. The gcc build logic must be messed up for amd64.. Can you look at it and attach patches if needed. That symbol should of never been enabled in your gcc. The __guard is only supposed to live in glibc now.
Beside the guard problematic (that only comes up with -fstack-protector) there is another problem: On amd64 there seems to be the need to compile any library with -fPIC that gets linked with -pie, even static ones. Best example is this app. I patched the makefiles to allow compilation of any .o with -fPIC and make returned the following in the final linking step: gcc -O2 -fomit-frame-pointer -pipe -fPIC -fPIC -Wunused -Wall -pie -o modprobe modprobe.o libsupport.o -Wl,-Bstatic -lz -Wl,-Bdynamic /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../libz.a(gzio.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../libz.a: could not read symbols: Bad value collect2: ld returned 1 exit status When looking at zlib(-1.2.1-r2) you see a patch that let all object files be compiled twice, one time without -fPIC to be linked to a static lib, the second time with -fPIC to be linked to a shared one. Question is: Shall _any_ lib (static or not) be compiled -fPIC on amd64 or shall this depend on the content of LDFLAGS ?
The "-fstack-protector" issue appears to be solved for me now, see Bug #46697.
due to the nature of PIE and amd64, it seems that /everything/ will need to be -fPIC and so any additional makefile/ebuild magic would be redundant with -fPIC as a default always-on CFLAG. PIE turns all executables into shared libraries that you can run, and on amd64 you cant build any shared libraries without -fPIC... solar - should i also re-assign this bug to myself since you dont have an amd64 box to test with?
Ok I assume at this point your toolcahin is in basic order.. So.. module-init-tools/modutils are two known pkgs that have problems with -fPIC/-pie In the long run I/we want to address this at the source code level and find out where said code in not PIC aware and recode it to be PIC aware. Sometimes it's easy sometimes it's not.. Note: -static & -pie have been known to not play along together on x86.
this problem is solved by using: ayanami gcc # gcc --version gcc (GCC) 3.4.0 20040416 (prerelease) (Gentoo Hardened Linux 3.4.0_pre20040416, pie-8.5.3) and, i assume, gcc 3.3.3-r2 as well.
