混淆exe的靜態編譯agaisnt不同版本的圖書館w /共享內存

Question

我爲長期的問題提前道歉，但我想確保我沒有遺漏任何可能會改變你的反應的關鍵點。

我負責維護寫成「C」，而我們有一些共同的「一個」庫系統軟件。我們稱之爲「執行管理器」的主要工作是分叉和執行「測試作業」可執行文件的變量列表，並在測試作業過程終止後將控制權返還給執行管理器。所有可執行文件，包括執行管理器，都與上述庫靜態鏈接。執行管理器和測試工作進程通過共享內存分叉使用IPC。其中一個通用庫包含包裝函數，用於創建並附加永久不會更改的預定義密鑰的共享內存。

幾個月前，我們鎖定了我們的軟件（測試工作以及執行管理器），靜態編譯它們並釋放他們有與測試工作「發麪」。從那時起，有一些要求對執行管理器進行更改的請求，這將需要改變選定的少數通用庫函數。但是，管理層已經決定，他們不希望針對新版本的公共庫重新編譯測試作業，因爲這需要他們重新校對他們目前擁有的測試作業可執行文件;而且他們不想花錢去做那件事。

因爲所有的可執行文件進行靜態編譯，我通常會說混合測試工作靜態編譯針對不同版本的同一公共庫的將不會是一個問題的執行經理。然而，通過共享內存包含IPC讓我懷疑這是否仍然如此。我的直覺是，只要共享內存包裝函數沒有改變，尤其是關鍵，那麼我們應該沒問題，但我真的可以在這方面使用一些專家意見。

感謝百忙之中閱讀本文時，大加讚賞。

Answer 1

你應該可以，只要定義流程如何通過共享內存互相交談的數據結構和協議沒有改變。 （也就是說，這兩個進程之間存在的小ABI）。

Answer 2

我想證實什麼caf說。您已正確識別了關鍵位：用於訪問共享內存的密鑰和包裝函數。這些位不關心它們是否在.o文件中定義，它們是否是.a文件的一部分，或它們在.a文件中的位置。在鏈接時，他們被拉進exe文件，保持其原有的功能;他們在.a文件中的「臨時住所」並不影響他們如何找到共享內存段，他們如何確定相關的偏移量等。因此，如果這些（即密鑰和包裝函數）沒有改變，您應該設置。