[gentoo-hardened] TESTING kevquinn_overlays: amd64 hardened gcc - (bugzilla is down, i hope the mails are not)

[Alexander Gabert]

Kevin: this is the build failures, i would have made them end up adding 
into bugzilla but one of us both wasn't awake.

PSM: if you're reading up: i don't have a clue.

In the meantime, working with bugs.g.o. it's getting a real hassle, so 
can someone please kick that pos in the shins so we can work on bugs 
again?  TIA

I think we should have a talk or two and maybe a test case for building 
that libiberty on all arches with either PIC or PIE code.
I honestly don't care howe we build it, i just want it to work on all 
Gentoo supported arches for hardened.

For those of you having issues with the file: here is the log for pitr 
and miranda:

http://dev.gentoo.org/~pappy/tmp/amd64-pie-libiberty-failure.txt

Here is what it says on the #gcc channel- no big deal anyway.

07:24 < pappy-_> what is the role of libiberty, for what is it used 
during building gcc
07:24 < pinskia> zwol: a million dollar question
07:25 < pinskia> pappy-_: to support OS's that don't have some system 
functions and also to add some
           functions which are abstractions like launching programs
07:25 < pinskia> and also demangler
07:25 < pappy-_> does the code inside libiberty has to be PIC
07:25 < pappy-_> on all arches?
07:25 < DrNick> most importantly, it's linker command line is -liberty
07:25 < pinskia> DrNick: :)
07:25 < DrNick> which I think was the deciding factor in it's creation
07:26 < pinskia> pappy-_: it only builds that for the target side
07:26 < pinskia> and not for the host or build sides
07:27 < pappy-_> yes, but it also uses it for generating stage2 stuff 
from stage1
07:27 < pappy-_> the host cc is used for building it in stage1
07:27 < pappy-_> and the stage1 libiberty (correct me if i'm wrong) is 
used for stage2 creation
07:27 -!- don2718 [~chatzilla@×××××××××××××××××××××××××.net] has quit 
[Ping timeout: 480 seconds]
07:28 -!- don2718 [~chatzilla@×××××××××××××××××××××××××.net] has joined #gcc
07:29 < pinskia> pappy-_: but that is still a host library
07:32 -!- Lightkey [~jonas@×××××××××××××××××××××××××××××××××××.net] has 
joined #gcc
07:33 -!- gabor [~ggreif@××××××××××××××××××××××.net] has joined #gcc
07:35 < pappy-_> /usr/x86_64-pc-linux-gnu/bin/ld:
 
../build-x86_64-pc-linux-gnu/libiberty/libiberty.a(hashtab.o): 
relocation R_X86_64_32S
           against `a local symbol' can not be used when making a shared 
object; recompile with -fPIC
07:35 < pappy-_> ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a: 
could not read symbols: Bad value
07:35 < pinskia> %tell dnovillo I found the fix for the latent bug, it 
was in phicprop pass and it was
           because EXECUTE_IF_SET_IN_BITMAP does not like the bitmap to 
change from underneath itself
07:36 < gccbot> pinskia: The operation succeeded.
07:36 -!- kazu [~chatzilla@×××××××××××××××××××××××××××××××.net] has quit 
[Ping timeout: 480 seconds]
07:36 -!- rsandifo [~user@××××××××××××××××××××××.uk] has joined #gcc
07:36 < pappy-_> this happens when i compile the object code for 
libiberty.a with -fPIE
07:36 < pappy-_> to use it in stage2 fails with this relocation error
07:36 < pappy-_> which is creating PIE executables
07:37 < pappy-_> the 'problem' is that i thought i know a statical 
library contains object code for
           the code segment of executables.
07:37 < pappy-_> and that executables can contain code of that library
07:38 < pappy-_> so the object code inside that statical library should 
be pie in my understanding
07:38 < pappy-_> however, it doesn't seem to be the reality
07:42 < pappy-_> ?


I'm catching up on some REM phase now, cya


Alex