chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

編譯鏈接的套路有哪些?

Q4MP_gh_c472c21 ? 來(lái)源:程序喵大人 ? 作者:程序喵大人 ? 2021-02-10 10:06 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

不知道大家平時(shí)編程過(guò)程中使用動(dòng)態(tài)鏈接庫(kù)的情況多不多,如果一個(gè)程序引用了無(wú)數(shù)個(gè)動(dòng)態(tài)鏈接庫(kù),那就有可能引入符號(hào)沖突的問(wèn)題,問(wèn)題如下:

想象中

5236e7f8-5f63-11eb-8b86-12bb97331649.png

實(shí)際上

5236e7f8-5f63-11eb-8b86-12bb97331649.png

下面,我們嘗試解決它。

最開(kāi)始介紹下g++基本命令參數(shù):

g++-c 編譯源文件,但是不進(jìn)行鏈接-o 指定輸出文件的名字-s strip,移除符號(hào)信息-L

指令搜索鏈接庫(kù)的路徑-l 指定要鏈接的鏈接庫(kù)-shared 產(chǎn)生動(dòng)態(tài)目標(biāo)文件

先來(lái)看一段代碼:

#include voidDoThing(){printf("work ");}

再定義一個(gè)簡(jiǎn)單的main.cc程序:

#include voidDoThing(); intmain(){printf("start ");DoThing();printf("finished ");return0;}

編譯這兩個(gè)文件,并分別打包成靜態(tài)庫(kù):

g++ -c work.cc -o work.oar rc libwork.a work.og++ -c main.cc -o main.oar rc libmain.a main.o

現(xiàn)在將這兩個(gè)靜態(tài)庫(kù)鏈接成一個(gè)可執(zhí)行文件,注意鏈接器如果發(fā)現(xiàn)當(dāng)前庫(kù)中使用了沒(méi)有被定義的符號(hào),它只會(huì)向后查找,因此最低級(jí)別沒(méi)有其它依賴的庫(kù)應(yīng)該放在最右邊,如果出現(xiàn)了符號(hào)沖突問(wèn)題,鏈接器會(huì)使用最左邊的符號(hào)。

如果這樣進(jìn)行鏈接:

$ g++ -s -L. -o main.exe -lwork -lmain./libmain.a(main.o): In function `main':main.cc undefined reference to `DoThing()'collect2: error: ld returned 1 exit status

鏈接失敗,因?yàn)閙ain庫(kù)里的DoThing符號(hào)沒(méi)有被定義,鏈接器向后查找,沒(méi)有找到對(duì)應(yīng)的符號(hào)定義,這里更改下鏈接庫(kù)的順序:

g++-s-L.-omain.exe-lmain-lwork$./main.exestartworkfinished

鏈接成功。

現(xiàn)在寫(xiě)一個(gè)簡(jiǎn)單的容易產(chǎn)生符號(hào)沖突的文件conflict.cc:

#include voidDoThing(){printf("conflict ");}

編譯并打包成靜態(tài)庫(kù):

g++-cconflict.cc-oconflict.oar rc libconflict.a conflict.o

如果按這樣的順序鏈接成一個(gè)可執(zhí)行程序:

$g++-s-L.-omain.exe-lmain-lwork-lconflict$./main.exestartworkfinished

如果稍微更改一下鏈接的順序:

$g++-s-L.-omain.exe-lmain-lconflict-lwork$ ./main.exestartconflictfinished

這里發(fā)現(xiàn)順序的不同導(dǎo)致了程序輸出內(nèi)容不同,究其原因就是那潛在的符號(hào)沖突。

現(xiàn)在再試試動(dòng)態(tài)庫(kù),先介紹如何使用動(dòng)態(tài)庫(kù):

$rmlibconflict.a$g++-sharedconflict.o-olibconflict.so$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartconflictfinished

現(xiàn)在再引用一個(gè)中間層在動(dòng)態(tài)鏈接庫(kù)中調(diào)用conflict的文件layer.cc

#includevoidDoThing();voidDoLayer(){printf("layer ");DoThing();}

并把layer和conflict打包成一個(gè)動(dòng)態(tài)鏈接庫(kù):

$g++-clayer.cc-olayer.o$ g++ -shared layer.o conflict.o -o libconflict.so

然后更新main.c程序,main里面調(diào)用layer,layer里調(diào)用conflict:

#includevoidDoLayer();intmain(){printf("start ");DoLayer();printf("finished ");return0;}

編譯鏈接執(zhí)行:

$g++-cmain.cc-omain.o$arrclibmain.amain.o$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartlayerconflictfinished

正常輸出,沒(méi)啥問(wèn)題,現(xiàn)在再把之前的work.cc也塞到main.cc中,觀察下沖突:

#includevoidDoThing();voidDoLayer();intmain(){printf("start ");DoThing();DoLayer();printf("finished ");return0;}

把work.o和main.o打包成一個(gè)庫(kù),之后和conflict鏈接成一個(gè)可執(zhí)行程序,運(yùn)行:

$g++-cmain.cc-omain.o$arrclibmain.amain.owork.o$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartworklayerworkfinished

這里輸出了兩個(gè)work,正常情況下第二個(gè)work應(yīng)該輸出conflict,怎么解決呢?

可以考慮使用-fvisibility=hidden來(lái)隱藏內(nèi)部的符號(hào),鏈接庫(kù)內(nèi)部使用的符號(hào)把它隱藏掉,不讓它被導(dǎo)出,外部也不會(huì)改變它的調(diào)用路徑。

先使用nm看一下libconflict.so里面的符號(hào):

$nm-CDlibconflict.sow_ITM_deregisterTMCloneTablew_ITM_registerTMCloneTable000000000000065aTDoLayer()0000000000000672TDoThing()0000000000201030B__bss_startw__cxa_finalizew__gmon_start__0000000000201030D_edata0000000000201038B_end0000000000000688T_fini0000000000000528T_init U puts

如果把符號(hào)隱藏掉:

$g++-fvisibility=hidden-clayer.cc-olayer.o$g++-fvisibility=hidden-cconflict.cc-oconflict.o$g++-sharedlayer.oconflict.o-olibconflict.so再使用nm看一下libconflict.so里面的符號(hào):$nm-CDlibconflict.sow_ITM_deregisterTMCloneTablew_ITM_registerTMCloneTable0000000000201028B__bss_startw__cxa_finalizew__gmon_start__0000000000201028D_edata0000000000201030B_end0000000000000618T_fini00000000000004c0T_init U puts

這樣的話main函數(shù)肯定不能調(diào)用DoLayer啦,因?yàn)镈oLayer符號(hào)沒(méi)有暴露出來(lái):

$g++-s-L.-omain.exe-lmain-lconflict./libmain.a(main.o):Infunction`main':main.ccundefinedreferenceto`DoLayer()'collect2: error: ld returned 1 exit statu

那怎么暴露出來(lái)特定符號(hào)呢,直接看代碼,改動(dòng)了layer.cc:

#includevoidDoThing();__attribute__((visibility("default")))voidDoLayer(){printf("layer ");DoThing();}

再編譯鏈接運(yùn)行看看結(jié)果:

$g++-fvisibility=hidden-clayer.cxx-olayer.o$g++-sharedlayer.oconflict.o-olibconflict.so$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartworklayerconflictfinished

發(fā)現(xiàn)已經(jīng)是我們期待的結(jié)果啦,符號(hào)沖突的問(wèn)題因此被解決。

是不是感覺(jué)很麻煩,難道每個(gè)要暴露的符號(hào)都要加上__attribute__這種修飾嗎,這里其實(shí)可以寫(xiě)一個(gè)export文件,告訴編譯器要導(dǎo)出的所有符號(hào)有哪些。

export.txt {global:*DoLayer*;local:*;};g++ -Wl,--version-script=export.txt -s -shared layer.o conflict.o -o libconflict.so

但這種方式只有在gcc中才可以被使用,我在clang中嘗試使用但是失敗啦,所以為了兼容性不建議使用這種方式,還是消停的使用__attribute__來(lái)解決符號(hào)沖突問(wèn)題吧。

Tips

通過(guò)隱藏符號(hào)可以減小可執(zhí)行程序的大小,還可以解決符號(hào)沖突問(wèn)題,但有個(gè)缺點(diǎn),因?yàn)殡[藏了符號(hào),線上程序運(yùn)行時(shí)如果出現(xiàn)crash,通過(guò)堆棧信息我們看不到具體函數(shù)調(diào)用路徑,給定位問(wèn)題帶來(lái)了困難。所以,是否需要使用這種辦法,還應(yīng)根據(jù)實(shí)際情況具體抉擇。

原文標(biāo)題:原來(lái)編譯鏈接還有這么多套路……

文章出處:【微信公眾號(hào):嵌入式ARM】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 嵌入式
    +關(guān)注

    關(guān)注

    5198

    文章

    20404

    瀏覽量

    333347
  • 編程
    +關(guān)注

    關(guān)注

    90

    文章

    3716

    瀏覽量

    97117

原文標(biāo)題:原來(lái)編譯鏈接還有這么多套路……

文章出處:【微信號(hào):gh_c472c2199c88,微信公眾號(hào):嵌入式微處理器】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    入門(mén)篇:瑞芯微?RK?平臺(tái)編譯工具鏈自動(dòng)適配原理全解析

    配置交叉編譯器、指定路徑、配置環(huán)境變量,稍有偏差就會(huì)報(bào)「找不到gcc」「架構(gòu)不匹配」等錯(cuò)誤,折騰半天才能開(kāi)始正式編譯。 但用過(guò)瑞芯微官方SDK的開(kāi)發(fā)者都有一個(gè)直觀感受: 不用手動(dòng)配工具鏈,執(zhí)行編譯腳本,工具鏈自動(dòng)
    的頭像 發(fā)表于 02-11 07:10 ?3151次閱讀
    入門(mén)篇:瑞芯微?RK?平臺(tái)<b class='flag-5'>編譯</b>工具鏈自動(dòng)適配原理全解析

    一文詳解SystemC仿真庫(kù)的編譯

    AMD Vivado 設(shè)計(jì)套件以文件和庫(kù)的形式提供仿真模型。仿真庫(kù)包含器件和 IP 的行為和時(shí)序模型。編譯后的庫(kù)可供多個(gè)設(shè)計(jì)項(xiàng)目使用。用戶必須在設(shè)計(jì)仿真之前通過(guò)名為 compile_simlib 的實(shí)用程序編譯這些文件,以便為目標(biāo)仿真器
    的頭像 發(fā)表于 12-12 15:08 ?4776次閱讀
    一文詳解SystemC仿真庫(kù)的<b class='flag-5'>編譯</b>

    飛凌嵌入式ElfBoard-Vim編輯器之靜態(tài)鏈接和動(dòng)態(tài)鏈接

    mymath.c一起進(jìn)行,否則就會(huì)報(bào)錯(cuò)。(如下編譯正確)接下來(lái)是生成動(dòng)態(tài)鏈接庫(kù)的方法,gcc -shared xx -o xxx.so,當(dāng)我們使用cat去進(jìn)行查看的時(shí)候會(huì)發(fā)現(xiàn),so文件里全是亂碼,這就
    發(fā)表于 10-17 09:07

    通過(guò)rt_thread studio的setting加入CmBacktraceV1.4.1后編譯報(bào)鏈接錯(cuò)誤,怎么解決?

    通過(guò)rt_thread studio的setting加入CmBacktraceV1.4.1后編譯報(bào)鏈接錯(cuò)誤, cm_backtrace.c:173: undefined reference to `_stext\' 請(qǐng)問(wèn)怎么解決?
    發(fā)表于 10-09 06:40

    為什么RT Thread Studio 鏈接器無(wú)法正確讀取鏈接文件?

    大家好,我用RT Thread Studio 創(chuàng)建工程,然后下載相應(yīng)的編譯器,編譯源代碼,源碼編譯成功,但是最后鏈接時(shí)出現(xiàn)問(wèn)題: 。。。。 arm-none-eabi-gcc \&q
    發(fā)表于 09-02 08:22

    ubuntu編譯stm32cubmax生成的cmake工程,在最后鏈接階段報(bào)錯(cuò),怎么解決?

    我是直接stm32cubmax 生成的cmake 工程,我在Ubuntu 編譯的時(shí)候找不到這個(gè)-lc_none , 但是我看了我的編譯器安裝路徑一個(gè)nano.specs ,cmake 連接選項(xiàng)也有
    發(fā)表于 08-08 07:30

    飛凌嵌入式ElfBoard ELF 1板卡-uboot編譯鏈接文件uboot.lds

    編譯完成之后在uboot根目錄下生成的uboot.lds是鏈接文件。鏈接器就是通過(guò)這個(gè)文件將成千上萬(wàn)的.o文件鏈接在一起,此文件是根據(jù)arch/arm/cpu/uboot.lds生成
    發(fā)表于 05-22 11:20

    請(qǐng)問(wèn)如何鏈接動(dòng)態(tài)庫(kù)?

    是否可參考的工程? 鏈接成功后動(dòng)態(tài)庫(kù)應(yīng)該放在哪里啊?SDK是RTOS_ONLY
    發(fā)表于 04-25 08:15

    Linux內(nèi)核編譯失?。恳苿?dòng)硬盤(pán)和虛擬機(jī)的那些事兒

    Linux內(nèi)核卻失敗了,這是咋回事?FAT和NTFS文件系統(tǒng)不能支持軟鏈接,在這寫(xiě)格式的磁盤(pán)里編譯內(nèi)核會(huì)失敗,同樣也不能在這樣的磁盤(pán)里解壓內(nèi)核源碼,會(huì)造成軟鏈接被破
    的頭像 發(fā)表于 04-11 11:36 ?974次閱讀
    Linux內(nèi)核<b class='flag-5'>編譯</b>失???移動(dòng)硬盤(pán)和虛擬機(jī)的那些事兒

    GPU顯卡維修避坑指南:手把手教你識(shí)別行業(yè)套路!

    你的顯卡維修被“套路”過(guò)嗎?“一塊H100顯卡維修報(bào)價(jià)5萬(wàn)?修完3個(gè)月又壞!”你是否也遇到過(guò)——高價(jià)采購(gòu)的顯卡突然故障,返廠維修耗時(shí)數(shù)月,第三方服務(wù)商張口就是“核心損壞,必須換新”?在算力需求激增
    的頭像 發(fā)表于 04-02 20:31 ?3716次閱讀
    GPU顯卡維修避坑指南:手把手教你識(shí)別行業(yè)<b class='flag-5'>套路</b>!

    FPGA Verilog HDL語(yǔ)法之編譯預(yù)處理

    Verilog HDL語(yǔ)言和C語(yǔ)言一樣也提供了編譯預(yù)處理的功能。“編譯預(yù)處理”是Verilog HDL編譯系統(tǒng)的一個(gè)組成部分。Verilog HDL語(yǔ)言允許在程序中使用幾種特殊的命令(它們不是一般
    的頭像 發(fā)表于 03-27 13:30 ?1395次閱讀
    FPGA Verilog HDL語(yǔ)法之<b class='flag-5'>編譯</b>預(yù)處理

    KiCad直播活動(dòng)(三):在 Windows上編譯KiCad 手把手教您編譯/構(gòu)建 KiCad 源碼

    親愛(ài)的 KiCad 粉們: 本周繼續(xù) KiCad 的直播活動(dòng),我們將在 3 月27 日周四晚 19:30 為您帶來(lái) “在 Windows 上編譯 KiCad” 的專題!邀請(qǐng)了 KiCad Lead
    的頭像 發(fā)表于 03-24 11:14 ?1621次閱讀
    KiCad直播活動(dòng)(三):在 Windows上<b class='flag-5'>編譯</b>KiCad 手把手教您<b class='flag-5'>編譯</b>/構(gòu)建 KiCad 源碼

    STM32CubeIDE編譯設(shè)置是否像keil一樣編譯后執(zhí)行Bat腳本的功能和設(shè)置?

    STM32CubeIDE編譯設(shè)置問(wèn)題,是否像keil一樣編譯后執(zhí)行Bat腳本的功能和設(shè)置?或者相關(guān)的腳本和插件?
    發(fā)表于 03-14 15:59

    cubeide的代碼怎么編譯到內(nèi)部+外部FLASH里面去?

    一個(gè)項(xiàng)目,準(zhǔn)備使用GUI和AI,準(zhǔn)備使用STM32U5,但是編譯出來(lái)的代碼很多,STM32U5的內(nèi)部FLASH不夠用,準(zhǔn)備使用OSPI擴(kuò)展外部FLASH。但是遇到一個(gè)問(wèn)題,我不知道怎么將編譯
    發(fā)表于 03-07 07:48

    MolunSmartHome蝦哥小智源碼編譯固件演示

    蝦哥小智Ai對(duì)話項(xiàng)目固件編譯演示
    的頭像 發(fā)表于 02-24 12:21 ?1w次閱讀
    MolunSmartHome蝦哥小智源碼<b class='flag-5'>編譯</b>固件演示