linux 編譯時候的 fPIC 問題

[orzuk-lmj]

• 首先給一段測試用的腳本，大致上長這個樣子：

  target("static_library")
      set_kind("static")
  
  target("shared_library")
      add_deps("static_library")
      set_kind("shared")
  
  target("exec_app")
      add_deps("static_library")
      add_deps("shared_library")
      set_kind("binary")

• 使用非常簡單的 c++ 代碼測試函數呼叫的連結相依姓，然後確定都使用 cmake 在全平台編譯通過且可執行。

• 目前用xmake 最新的dev分支，有測試過的 linux 分別是 centos7(gcc4.8) / ubuntu18 (gcc7.2) / manjaro (gcc8.2)

• 在 xmake 使用中，以上所有 -m32 設置 -a i386 都可以正常編譯執行。

• 使用 -m64 設置 -a x86_64 編譯期間 shared library 會出錯，而且錯誤只發生在 centos7 這個環境下。

  relocation R_X86_64_32 against `.bss' can not be used when making a shared object; 
  recompile with -fPIC
  

• 因為問題只發生在 centos7 環境，所以我仔細檢查了一下編譯時.dep目錄中的 *.cpp.d 內容設置的旗標，發現-fPIC不存在，因此我在 target("static_library") 裡也特別加入了 add_cxflags("-fPIC") 去重新編譯，結果就成功了。。。

• 整理了一下思路，貌似是被 shared library 使用的 static library 沒有使用 -fPIC 編譯，然後這些linux環境個別使用不一樣的預設編譯參數導致。。。xmake 運行config 的時候適合幫 static library 自動補上-fPIC 嗎?

[waruqi]

-fPIC这个，目前通过shared_library -> add_deps(static_library)的方式，static_library确实还不会去自动加的。

之前的版本编译正常吗，应该也是没加-fPIC的。。还是只有dev版本才有这问题？

目前只能通过用户自己add_cxflags("-fPIC") 去设置到依赖的static_library上去才行。。

依赖继承这块，目前做的还不是很好，对于-fPIC这种情况，我之后会考虑改进下的，可能需要先理下当前的依赖继承架构后，才能支持上，需要等上一段时间。

[orzuk-lmj]

之前的版本编译正常吗，应该也是没加-fPIC的。。还是只有dev版本才有这问题？

之前版本很湊巧的都使用在兩個正常的 linux 版本中(ubuntu/manjaro)，所以沒遇到問題。然而這次下載最新的dev分支則是直接在 centos 底下測試，剛剛好就撞上錯誤。

• ubuntu/manjaro下載的 xmake 新舊版本都運作良好
• centos 下載的 xmake 新舊版本都出現 fPIC 問題
• 估計系統預設的編譯旗標有差異

[waruqi]

那就不是新版本引出的问题，应该还是个老问题 只是之前没发现

这块你先自己手动设置下fpic吧 这块等之后我改进后 你在试试

[waruqi]

这块我会在https://github.com/xmake-io/xmake/issues/368里面，同时处理掉 内部继承-fPIC

[waruqi]

我又思考了下 这个问题，如果shared target用到了某个static target，这个static target也不应该自动补上-fPIC

如果只有share target在用它，那可以，关键是还有其他非share target也有可能会用到他们，这个就全局影响了

这个问题通过设置public flags 依赖导出也是解决不了的，因为这个是反向继承关系，子target去影响父target的flags，这个做法是有问题的

我建议这个问题的解决方式: 对需要在share target使用的static target根据用户实际需求，自己添加上-fPIC ，用户自己去处理是否添加-fPIC 更加可控些

[orzuk-lmj]

複雜的專案多個target倚賴的關係鏈處理起來不小心就出錯了，而且系統預設的編譯器選項也不相同，理論上應該會希望一般使用者跨平台編譯的時候不需要關注太多平台差異吧? 可以的話，會希望有比較方便的除錯提示。

若不自動補上-fPIC，也建議檢測到 shared target 用到 static target (無-fPIC) 的時候，至少要報出警告，比較容易定位出是哪一個target問題。

[waruqi]

自动对父target添加-fPIC，影响太广，容易影响其他用到了此target的其他target，我目前不打算加上这块处理。。

也建議檢測到 shared target 用到 static target (無-fPIC) 的時候，至少要報出警告，比較容易定位出是哪一個target問題。

如果出问题，编译时候已经有错误提示了，由于编译器种类繁多，这种提示处理无法100%做到准确，也许有些低版本gcc或者其他冷门编译不需要加-fPIC也能正常使用呢？

这种建议还是依赖编译器自身的提示更好，否则如果出现错误警告反而误导用户

relocation R_X86_64_32 against `.bss' can not be used when making a shared object; 
recompile with -fPIC

如果当前编译器编译的时候，没有提示编译错误，至少说明对于当前编译器生成的binary，即使部分library没有-fPIC，其生成的binary还是可用的，如果不可用，编译器自身就会报错了，错误信息更加精准。

[waruqi]

而且即使所有父static target都自动补上了-fPIC，但是引用的其他编译好的第三方static lib，xmake还是没法自动处理掉的，还是需要用户自己处理，因此对用户来讲，本身就没法完全做到无感知化

这部分已经编译好的第三方库，想要做检测是否已经带上了-fPIC，再提示警告，那就更加麻烦了，也不通用

[orzuk-lmj]

目前這個問題靠使用這多注意些的確已經可以解決，若僅為了fPIC就花太多時間也真的不太值得，感謝解釋。