x86_64で静的ライブラリをコンパイルするときに、gccが暗黙的に-fPICフラグを提供しないのはなぜですか

Question

静的ライブラリに対して静的にリンクする共有オブジェクトをコンパイルするときに、多くの問題が発生しました。この問題は、x84_64プラットフォームでのみ発生します。 x86_32で同じコンパイル作業を行う場合、問題はありません。

おそらくこれはOS固有のGCC構成のことですが、私の研究では、x86_64プラットフォームでGCCがどのように機能するかを示しています。とにかく、私はUbuntu 10.04 x86_64でgcc 4.4.3を使用しています。

問題はどのように修正されますか？...すべての静的ライブラリの依存関係が-fPICでコンパイルされていることを確認します。

質問1： -fpicと-fPICの違いは何ですか（どうやら-fPICはx86でより多くの命令を生成します）？なぜ後者のタイプはx86_64コンテキストでより関連があるのですか？

質問2：静的コードに対してリンクすると、リンク時に関数をバイナリにハードワイヤリングしているのに、「位置に依存しないコード」機構が提供する間接参照のレベルが必要なのはなぜですか？ ？

質問3：ここで、x86が-fpic/-fPICを必要としない場合、静的オブジェクトに対して共有オブジェクトをリンクするのに、なぜx86_64で必要なのですか？

質問4：必要な場合でも、暗黙的に提供されないのはなぜですか？変更を壊すのは大きなノーノーだと思った

Answer 1

1. 質問 544035 を参照してください。 here および there についても説明します。
2. 静的ライブラリの用途によって異なります。それをプログラムにリンクするだけの場合は、PICコードは必要ありません（libtoolは便利なライブラリを呼び出します。これを使用しなくても、ほとんどの場合、これは、コンパイルプロセスを適切なサイズにするのに役立ちます）。それ以外の場合、共有ライブラリをリンクする場合は、静的ライブラリにPICコードが必要です。
3. 質問 146744 および ここ も参照してください
4. それはあなたのコードを膨らませるので、それはデフォルトではありません。確認するべきことの1つは、単一のオブジェクトファイルをコンパイルするとき、GCCはそれから共有ライブラリを作成するかどうかを知らないということです。ほとんどの小さなプロジェクトでは、いくつかのオブジェクトファイルをリンクするだけで、PICコードなどは必要ありません。

また、私のアドバイスは次のとおりです。それについて心配する必要がある場合は、それを間違っています（または、難しい方法を学びたい場合は、経験からより多くを得ることができるので、ニースです）。コンパイルシステム（libtool、cmakeなど、使用するものはすべて）がそれを行うはずです。