移動庫和頭文件

我有一些c代碼，它提供了libfoo.so和libfoo.a以及頭文件foo.h.大量的客戶端目前使用這些來自/ old_location/lib和/ old_location/include目錄的庫，這些目錄是它們被分配的地方。移動庫和頭文件

現在我想將此代碼移至/ new_location。然而，我無法告知客戶這種變化。我希望舊客戶端繼續訪問/ old_location中的庫和頭文件。

爲此，將創建符號鏈接到libs /頭到新的位置工作？

/old_location/lib/libfoo.so -> /new_location/lib/libnewfoo.so 
/old_location/lib/libfoo.a -> /new_location/lib/libnewfoo.a 
/old_location/inlcude/foo.h -> /new_location/inlcude/foo.h

[請注意，我需要來命名新的lib爲lib中新 foo和由於某些限制不libfoo的。這個重命名可以導致任何問題嗎？然而，生成這些代碼的C代碼沒有改變。]

它似乎適用於我試過的幾個簡單案例。但是，在有些情況下，客戶使用庫和頭文件的方式可能會因此更改而崩潰。請讓我知道這可能涉及什麼樣的錯綜複雜。對不起，如果這似乎是一個新手問題，我以前幾乎沒有與c工作過，並且是一個java人。

來源

2010-01-14 baskin

您必須區分編譯時間和運行時間。

對於編譯時，客戶端需要更新他們的Makefile和/或配置邏輯。

對於運行時，您只需通過通過ld.so.conf瞭解在哪裏可以找到.so庫（或者告訴客戶調整LD_LIBRARY_PATH，這是第二個最佳選擇）。靜態庫不重要，因爲它的代碼已經內置到可執行文件中。

是的，通過提供符號鏈接，您可以使移動「消失」，並通過舊位置提供所有文件。

而且所有這些都是在推出之前從您的結尾進行測試。

來源

2010-01-14 13:36:19

感謝德克響應。我特別關心將庫從libfoo重命名爲libnewfoo。你認爲這是否會造成麻煩？ – baskin 2010-01-14 13:50:32

是的，如果客戶端使用動態鏈接，那麼很可能會破壞_run time_。 – 2010-01-14 14:40:46

我沒有看到任何理由爲什麼這會中斷，這是一個關於符號鏈接比C的問題。對於一個不知情的用戶程序（沒有特殊代碼來檢測符號鏈接和抱怨），符號鏈接是透明。

如果您遇到錯誤，請隨時發佈，我們將盡我們所能提供建議。然而，我看不出任何會導致問題的東西。

來源

2010-01-14 13:38:21

符號鏈接可以在任何支持符號鏈接的操作系統和文件系統上運行。

來源

2010-01-14 13:38:46

符號鏈接的唯一問題可能是，如果某些客戶端使用不同的路徑裝載新位置，這可能在聯網的unix類型環境中。例如，你可以有位置爲：

/var/stuff/new_location/include/...

和客戶端可以安裝作爲：

/auto/var/stuff/new_location/include/..

在這種情況下，相對的符號鏈接可能會更好地工作，即：

old_location/include/foo.h -> ../new_location/include/foo.h

另一個要考慮的是更換OLD_LOCATION/foo.h中有：


/* 
* Please note that this library has moved to a new location... 
*/ 
#include "new_location/include/foo.h"

來源

2010-01-14 13:57:44

移動庫和頭文件

回答

相關問題