為什么C程序針對C ++庫編譯並與C編譯器鏈接，然后在運行時進行SIGILL？

Question

最近，我在IBM AIX上編寫的3rd party插件出現問題。 跟蹤花費了大量時間。 該插件采用C可執行文件的形式。 該可執行文件是根據第三方庫進行編譯的。 提供了這些庫的新版本以進行強制升級。

與IBM C編譯器12.1編譯並鏈接后，如果使用OLSON設置時區，並且SIGILL崩潰，則現有代碼將生成一個二進制文件，如果使用POSIX設置時區，則二進制文件將不可用。

使用調試printfs到日志文件並刷新日志文件，我能夠相當迅速地跟蹤到對第三方API調用的崩潰。 但是第三方供應商花了一些時間才提到新版本的API在其自己的代碼中引入了C ++庫的使用。

通過使用IBM C編譯器進行編譯，但與IBM C ++鏈接器（xlC）鏈接，解決了該問題。

所以我的問題是：

1）為什么C鏈接器沒有生成有效的可執行文件？

必須生成了半有效的二進制文件，否則代碼將在OLSON時區下無法正常工作。 這意味着所有符號都存在，並且處理了所有名稱更改（盡管可能不正確）

2）如何確定編譯器和鏈接器生成的二進制文件是否有效？

我認為做到這一點的唯一方法是在單元測試中盡可能地充分執行代碼。

3）如何防止不同代碼出現類似情況？

我應該始終與C ++鏈接程序鏈接嗎？ 這對我來說似乎不對。

抱歉，我無法發布代碼，但我不能隨意這樣做。

Answer 1

Zsigmond有很多不錯的陳述。 我們至少需要查看鏈接線及其選項，對您有很大幫助。 帶有“忽略未解析的符號”的開源鏈接通常不理解，因為它們不理解導入文件。 因此，鏈接將成功生成完全無用的二進制文件-原因就是為什么要這樣做。