Christoph Mende wrote:
> One thing that I think wasn't mentioned yet, while -fPIC is needed for
> libraries, it must be disabled for binaries (don't know if that's true
> for prelink), as portage says, it might break things and your binaries
> are most likely becoming slower when you compile them with -fPIC.
>
Unfortunately I am not a C programmer and I can't be sure about how
exactly PIC and prelink work.
As far as I understood the mechanism (please, correct me if I'm wrong)
prelink scans the executables to find which libs they load. Then it
makes cache and when a program is started it uses already pre-loaded
libs. So the program is ready for action faster.
My only way to judge about the result is to test. Taking this in mind
you can understand that the part about "becoming slower" sounds very
disturbing to me. ;-)
Can you, please, explain how it comes that PIC is good for libs and bad
for execs? I'm confused because the gcc man page says:
-fpic
Generate position-independent code (PIC) --snip--
If the GOT size for the linked executable exceeds a
machine-specific maximum size, you get an error message
from the linker indicating that -fpic does not work; in that
case,
recompile with -fPIC instead. -snip- *The 386 has no such limit*
-fPIC
If supported for the target machine, emit position-independent
code, suitable for dynamic linking and avoiding any limit on the
size of the global offset table. *This option makes a
difference on
the m68k, PowerPC and SPARC.*
So, both flags let gcc produce PIC for libs and programs and none of
them lets gcc produce PIC for libs only? The next flag described in the
man page is -fpie, which makes PIC for programs only. Something is wrong
and don't know how to find the right explanation.
--
Best regards,
Daniel
--
gentoo-amd64@gentoo.org mailing list
