Bug 46367 – module-init-tools gives additional -fPIC errors on amd64 with pie

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Travis Tilley (RETIRED) 2004-03-31 08:05:22 UTC]

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

[Comment 1 Travis Tilley (RETIRED) 2004-03-31 08:09:22 UTC]

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?

[Comment 2 solar (RETIRED) 2004-03-31 08:26:30 UTC]

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.

[Comment 3 Danny van Dyk (RETIRED) 2004-04-02 16:06:35 UTC]

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 ?

[Comment 4 Danny van Dyk (RETIRED) 2004-04-03 09:35:15 UTC]

The "-fstack-protector" issue appears to be solved for me now, see Bug #46697.

[Comment 5 Travis Tilley (RETIRED) 2004-04-13 16:36:49 UTC]

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?

[Comment 6 solar (RETIRED) 2004-04-13 19:22:50 UTC]

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.

[Comment 7 Travis Tilley (RETIRED) 2004-04-19 11:53:56 UTC]

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.