I have an alpha, but I would be surprised if it isn't a problem on all 64bit platforms. For libraries alpha requires -fPIC to be able to move code around in memory. at least for shared libraries. (*.so stuff) Notable exeption seems to be the plain old libraries. At least when libtool is used to build stuff the --dynmaics are almost allways compiled with -fPIC -DPIC added to the CFLAGS. When building freeradius I ran into the following problem: when building the rlm_unix dynamic module (trace follows) it tries to link with -lshadow, there is no libshadow.so (i'll get into that a bit later.) so libtool will make that a "-Wl,--whole-archive /usr/lib/libshadow.a -Wl,--no-whole-archive" sequence. rlm_unix is dynamic, but libshadow.a IS NOT compiled with -fPIC therefore the following errors are logged: ---8<--- /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol wipe_clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol wipe_clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol clear_pass ---8<--- hinting that libshadow.a should be compiled with -fPIC. If a libshadow.so were existent all would have gone well, as -dynamic modeles get built with -fPIC. Trying to build shadow-4.0.3-r9 it shows it DOES NOT BUILD .so libraries it even says in the release notes they are deleted. Building it will show that dynamic building fails because of a missing -lpam -lpam_misc library during linkg. IMHO it would be wise to ALLWAYS use -fPIC on 64bit platforms even for static libraries because the programs can easily get larger than originaly was in mind of the developer.
Nico, thanks for the bug, and for the completeness of the information you've provided. You might find this email interesting: http://marc.theaimsgroup.com/?l=gentoo-dev&m=107112691504786&w=2 I think for now we'll just continue fixing ebuilds that need -fPIC so that we don't break other programs/libraries that don't want it. Check out shadow-4.0.3-r10.ebuild which should fix this problem for you (presently ~arch masked because it freaks me out to touch such a critical package ;-)
Hmm, I'm reading this bug more carefully and considering that it would be better to fix bug 37725 so that -fPIC isn't needed on the .a version of the shadow library...
Okay, I fixed bug 37725 by enabling building of libshadow.so, which should solve the problem for freeradius. This change is in shadow-4.0.3-r10.ebuild. Regarding the request to have libtool always use -fPIC, as mentioned previously, I don't think that is the right solution. So I'm closing this bug WONTFIX. Thanks!
I agree that this could have huge impact. It would probably fix a lot of problems for 64bit platforms, but might open quite a can of worms .... Thanks....
after reading this http://marc.theaimsgroup.com/?l=gentoo-dev&m=107112691504786&w=2 I can understand the issues raised there make a point for x86 & 32 bit architectures. The more modern 64bit architectures often have a lot or abundant (ia64) registers. the claim that 1 register is too precious to prevent software especialy libraries suffer seems a bit void here. The problem with 64bit architectures is that there are no ways of directly reference a 64bit address without a base reference. Most of the times the instructions are about 32bit and loading a register with a constant also need some of those bits as opcode. therefore on 64bit architectures a claim for allways using -fPIC seems credible to me. I still think it will open quite a can of worms, but that might happen anyway...? Thanks so far.
The actual policy with -fPIC is that we do not enable it automatically, and if something breaks, we fix it and let upstream know, so that they can fix it ...
