bash gives an fPIC error when compiling on amd64 with pie: gcc -pie -rdynamic -O2 -fomit-frame-pointer -pipe -fPIC -fstack-protector -o mkbuiltins mkbuiltins.o -ldl /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: mkbuiltins.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC mkbuiltins.o: could not read symbols: Bad value this bug only surfaces with pie. a temp fix will probably be `use amd64 && filter-ldflags`, but the goal is to get pie working.
Created attachment 28532 [details, diff] Patch for sys-apps/bash-2.05b-r9.ebuild to allow compilation with CFLAGS containing "-pie" on amd64 Works for me with above patch.
Thats no good... from a quick glance you are applying -fPIC as a CFLAG to all objects in bash, when we only want to apply it to shared objects.
*** Bug 46364 has been marked as a duplicate of this bug. ***
Created attachment 28534 [details, diff] Patch to only compile builtins/mkbuiltins.c with "-fPIC" in case that CFLAGS contains "-pie"
Created attachment 28535 [details, diff] Patch for app-shells/bash-2.05b-r9.ebuild to allow compilation with CFLAGS containing "-pie" on amd64 Works for me with above patches. I hope this solution is better than the first ;-)
I'm admittedly not a Make expert, but this second fix looks golden to me. Apply -fPIC only in the appropriate spot. The ebuild patch is slightly incorrect, for this reason: -fPIC should be enforced on shared libs on all architectures, but is only strictly required on a few, eg amd64. On this note, -fPIC for shared libs should be our policy for all architectures, not only those with a strict requirement. I propose that for the time being, some folks test this patch, and we apply it regardless of architecture. Also, the patch should be pushed upstream as a bug against Bash. Volunteers? :P
http://www.gentoo.org/proj/en/hardened/pic-internals.xml For those following along, here is a reference on PIC, which better explains my last comment.
sorry, I was gone for a bit. I'd like to note that -pie is an LDFLAG and not a CFLAG. I should have mentioned this in my bug report, but at the time I was only filing it so that I wouldn't forget to fix it later (but I forgot to fix it later...). thanks for picking up my slack dude. once again, you rock. ;)
Hm, I'd like to apply that patch on amd64 generally, not only when LDFLAGS contains "-pie". Is that okay for everyone ?
i've been too busy with other general amd64-related bugs to much work on hardened-related stuff, but PIE forces everything to be position independant so it requires things to be -fPIC that normally shouldn't be. these errors /should/ pop up on x86, but it seems that since amd64 doesnt support shared libs not compiled with -fPIC it complains more loudly. really, that's all a PIE binary is.. a shared library with extra objects for calling constructors/destructors, an entry point, startup code that calls main(). very similar to what glibc does (open a term and type /lib/libc.so.6) additional -fPIC fixes should only be needed if -pie is in LDFLAGS (not CFLAGS) i'm going to re-assign all the pie bugs to myself as i still dont know exactly what kind of solution we need to port hardened to amd64 successfully. it's sounding like -fPIC should be a default always-on CFLAG when using PIE... in which case, any additional makefile/ebuild magic would be redundant. i'll poke solar with a stick and get his opinion. ;)
Please tell me if this is still a problem after trying the temp gcc-3.3.3-r1.ebuild that I pointed you at. I expect it to not be a problem when using it.
new gcc patch avoids this problem entirely, as it enables -fPIC and PIE by default when pax is in USE. testing...
this is a non-issue with gcc-3.3.3-r2 or the gcc 3.4.0 pre-release when hardened is in USE. everything is compiled -fPIC.
