2012-04-21 5 views
0

CentOS 5.1 g ++ 4.1.2および4.6.3および4.7.0でテストされていますが、それらはすべて同じ結果を生成します。これをどうすれば解決できますか?基本的に私はDebugビルドでllvmをビルドすることはできません。gcc -gは-fPICと競合しますか?

[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 

答えて

0

これらは動的再配置ではありません。それらはリンク時に解決されます。これは-fPICを破らない。

スタティックとダイナミックの2種類のリンクがあります。静的リンクは、オブジェクトファイルから最終プログラムバイナリをコンパイルするときにコンパイラ/リンカによって実行され、動的リンクはOSによって実行されます(linuxの場合はld-linux.so)。

動的再配置のリストを取得するには、objdump -Rを使用してください。ただし、動的にリンクされたバイナリでのみ動作します(つまり.oファイルではありません)。

+0

これは間違っています:http://sourceware.org/ml/binutils/2006-09/msg00142.htmlそれでは、ビルド中に "再配置R_X86_64_PC32"エラーを見つける最良の方法は何ですか?私はGoogleで検索しましたが運がありません。 –

+0

このエラーを再現できる唯一の方法は、-fPICなしでコンパイルされたオブジェクトを共有ライブラリにリンクしようとすることです。あなたがリンクした投稿の場合、バグかもしれません、またはポスターがちょうどファイルを混乱させるかもしれません - おそらくyuv2rgb.oの2つのコピーがありますか?これは珍しいことではありません。 –

+0

つまり、動的再配置の確認方法が間違っていました。 -gを使用しているときにのみ共有ライブラリをリンクする際に問題がある場合は、おそらくgccのバグです。 –

1

どうすれば解決できますか?

解決する問題はありません(問題の兆候は現れていません)。

そして、いや、-g-fPIC完全互換性があり、お互いにない競合を行います。

関連する問題