List Archive: gentoo-amd64
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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:
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
recompile with -fPIC instead. -snip- *The 386 has no such limit*
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
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.
email@example.com mailing list