gcc -g conflicts with -fPIC?

Question

Tested under CentOS 5.1 g++ 4.1.2 and 4.6.3 and 4.7.0, they all produce same results. How do I solve this? Basically I can't build llvm with Debug build.

[hidden]$ cat x.cpp #include <iostream> int main() { } [hidden]$ g++ -c -fPIC -g x.cpp [hidden]$ objdump -r x.o | grep R_X86_64_32 | head -10 000000000000001c R_X86_64_32 .debug_frame 0000000000000044 R_X86_64_32 .debug_frame 000000000000006c R_X86_64_32 .debug_frame 0000000000000006 R_X86_64_32 .debug_abbrev 000000000000000c R_X86_64_32 .debug_str+0x0000000000000414 0000000000000011 R_X86_64_32 .debug_str+0x00000000000007f2 0000000000000015 R_X86_64_32 .debug_str+0x000000000000017b 0000000000000029 R_X86_64_32 .debug_line 000000000000002e R_X86_64_32 .debug_str+0x0000000000000422 0000000000000034 R_X86_64_32 .debug_str+0x0000000000000607

Employed Russian · Accepted Answer · 2012-04-21 15:04:12Z

How do I solve this?

You don't have a problem to solve (you haven't shown any signs of the problem existing).

And no, -g and -fPIC are perfectly compatible and do not conflict with each other.

Michael Slade · Accepted Answer · 2012-04-21 00:59:10Z

0

These are not dynamic relocations. They will be resolved at link time. This does not break -fPIC.

Remember there are two kinds of linking, static and dynamic. Static linking is done by the compiler/linker when you compile the final program binary from the object files, and dynamic linking is done by the OS (ld-linux.so in the case of linux).

To get a list of dynamic relocations, use objdump -R. It will only work on dynamically linked binaries, however (i.e. not .o files).

edited Apr 21, 2012 at 0:59

answered Apr 21, 2012 at 0:32

Michael Slade

13.9k2 gold badges41 silver badges44 bronze badges

3 Comments

Kan Li Over a year ago

so this is wrong: sourceware.org/ml/binutils/2006-09/msg00142.html. Then what's the best way to figure out the "relocation R_X86_64_PC32" error while building? I searched on Google but with no luck.

Michael Slade Over a year ago

The only way I can reproduce that error is by attempting to link objects compiled without -fPIC into a shared library. In the case of the post you linked it may be a bug, or ther poster may have just gotten files confused - maybe there are two copies of yuv2rgb.o? This is not uncommon.

Michael Slade Over a year ago

i.e. The person was wrong about how to check for dynamic relocations. IF you are having problems linking a shared lib only when using -g then this is probably a bug in gcc.

Collectives™ on Stack Overflow

gcc -g conflicts with -fPIC?

2 Answers 2

Comments

3 Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

Comments

3 Comments

Related