2010-06-09 129 views
1

- 我試圖創建一個共享對象libfoo.solibfoo.so創建自foo.c - 假設我包含頭文件static.hDynamic.h,其中我希望編譯器能夠爲
解析Static.h的符號,並保留其餘部分,即從Dynamic.h運行時留下。 - 我該怎麼做?什麼是我需要通過的CFLAG和LDFLAG選項。 - 我的makefile被設置爲使用CFLAGS = fPIC,共享的W1,導出動態來創建一個共享對象。 - 在包含路徑中指定「Static.h」的正確位置GCC/C++共享對象中標題的靜態鏈接

有人可以幫我嗎?

+1

'static.h'中的符號來自哪裏?另一個庫? – 2010-06-09 17:16:51

+0

不,他們不來自另一個圖書館。我「期待」他們應該來自static.cc的目標代碼。我已經提供了正確的包含路徑,並希望編譯器從那裏得出結論。 – 2010-06-09 19:52:58

回答

0

我相信你所描述的功能實際上是你用GCC鏈接程序免費獲得的。在鏈接過程中,鏈接程序將解析您的代碼引用到在命令行上傳遞給它的庫的所有符號。如果引用的符號名稱包含在一個靜態庫(.a文件)中,它將被「靜態」鏈接,並且如果該符號位於動態鏈接庫(.so文件)中,它將在程序中動態鏈接執行時間處理時間。

一般而言,您不需要關心您的符號是靜態還是動態鏈接,因爲它應該對您的C/C++代碼沒有任何影響。從您的描述中,很難理解您的問題的動機,但您可能需要通過系統調用dlopen()明確加載動態鏈接庫。如果第一段沒有回答你的問題,你能描述一下你試圖解決的一般問題嗎?

+0

感謝您的回覆。 我正在擴展一個snmp代理並編寫* .so對象來提供擴展功能。 生成文件的摘要 CFLAGS + = $(INCDIRS)-shared -fPIC CFLAGS + = FNO嚴格混疊 LDFLAGS + =出口動態 SHLIB1 = SomeName.so SHLIB1_SRCS = foo.c的 和一堆通用於系統的makefile宏。 – 2010-06-09 19:58:55

+0

我一直在看 dlopen失敗:/SomeDir/lib/ifTable.so:undefined symbol:_ZN15SomeRecord4initER14TransactionRep 而這個的源頭是我包含的頭文件。一旦我刪除特定的頭文件,我沒有看到這個消息。 – 2010-06-09 20:09:32

+0

通常'未定義的符號'表示你忽略與所需的庫鏈接。找出哪個.so文件定義該符號(以及因此鏈接的符號)的一種方法是在.so上運行以下命令,該命令可能包含缺少的符號:'objdump -t .so | grep SomeRecord4init' – Rakis 2010-06-09 20:15:31

1

dlopen(),dlclose(),dlsym(),dlerror()是否有用於打開外部運行時庫的信息。 您必須聲明這些外部對象的函數指針,然後在運行時解析它們。

如果您只是在代碼中保留引用「裸」,鏈接器將嘗試解析該符號。它會解決它或拋出一個錯誤,從而不會得到一個executabel圖像。我不知道有任何鏈接器選項可排除嘗試鏈接未解析的符號。

或者我沒有得到你想要做的。

+1

它是'dlclose'而不是'dlfree' – 2015-09-03 08:14:22

+0

是的,謝謝你的糾正。 – 2015-09-03 19:58:13

0

只要所有的動態符號都在相應的頭文件中(通過extern)考慮,但可能未聲明,則在應用程序加載並定義符號時,運行時鏈接程序可以在稍後的時間點覆蓋它們,如果缺少一個或多個符號(如上面已經用SomeRecord4init報告的那樣),則運行時鏈接程序將填充缺失的位或可執行文件上的barf。您也可以將您的應用程序與庫(而不是使用libdl,這是一種痛苦,通過許多常見的構建/分析工具來追蹤lib依賴關係)相關聯。只要在CFLAGS中使用-shared而不是-static就可以做到這一點。

許多項目雖然在C庫中定義了面向私有和公共的API和字段。也許這就是你應該怎麼做來解決這個問題?

+0

還有弱符號與強符號的關係,但我故意掩蓋了這一點。 – yaneurabeya 2010-06-09 22:46:21

相關問題