• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            C++樂園

            C/C++ 交流

              C++博客 :: 首頁(yè) :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              12 隨筆 :: 18 文章 :: 14 評(píng)論 :: 0 Trackbacks
            學(xué)習(xí)VC++時(shí)經(jīng)常會(huì)遇到鏈接錯(cuò)誤LNK2001,該錯(cuò)誤非常討厭,因?yàn)閷?duì)于
            編程者來(lái)說(shuō),最好改的錯(cuò)誤莫過(guò)于編譯錯(cuò)誤,而一般說(shuō)來(lái)發(fā)生連接錯(cuò)誤時(shí),
            編譯都已通過(guò)。產(chǎn)生連接錯(cuò)誤的原因非常多,尤其LNK2001錯(cuò)誤,常常使人不
            明其所以然。如果不深入地學(xué)習(xí)和理解VC++,要想改正連接錯(cuò)誤LNK2001非
            常困難。
            初學(xué)者在學(xué)習(xí)VC++的過(guò)程中,遇到的LNK2001錯(cuò)誤的錯(cuò)誤消息主要為:
            unresolved external symbol “symbol”(不確定的外部“符號(hào)”)。
            如果連接程序不能在所有的庫(kù)和目標(biāo)文件內(nèi)找到所引用的函數(shù)、變量或
            標(biāo)簽,將產(chǎn)生此錯(cuò)誤消息。一般來(lái)說(shuō),發(fā)生錯(cuò)誤的原因有兩個(gè):一是所引用
            的函數(shù)、變量不存在、拼寫不正確或者使用錯(cuò)誤;其次可能使用了不同版本
            的連接庫(kù)。
            以下是可能產(chǎn)生LNK2001錯(cuò)誤的原因:
            一.由于編碼錯(cuò)誤導(dǎo)致的LNK2001。
            1.不相匹配的程序代碼或模塊定義(.DEF)文件能導(dǎo)致LNK2001。例如,
            如果在C++ 源文件內(nèi)聲明了一變量“var1”,卻試圖在另一文件內(nèi)以變量
            “VAR1”訪問(wèn)該變量,將發(fā)生該錯(cuò)誤。
            2.如果使用的內(nèi)聯(lián)函數(shù)是在.CPP文件內(nèi)定義的,而不是在頭文件內(nèi)定
            義將導(dǎo)致LNK2001錯(cuò)誤。
            3.調(diào)用函數(shù)時(shí)如果所用的參數(shù)類型同函數(shù)聲明時(shí)的類型不符將會(huì)產(chǎn)生
            LNK2001。
            4.試圖從基類的構(gòu)造函數(shù)或析構(gòu)函數(shù)中調(diào)用虛擬函數(shù)時(shí)將會(huì)導(dǎo)致LNK2001。
            5.要注意函數(shù)和變量的可公用性,只有全局變量、函數(shù)是可公用的。
            靜態(tài)函數(shù)和靜態(tài)變量具有相同的使用范圍限制。當(dāng)試圖從文件外部訪問(wèn)
            任何沒有在該文件內(nèi)聲明的靜態(tài)變量時(shí)將導(dǎo)致編譯錯(cuò)誤或LNK2001。
            函數(shù)內(nèi)聲明的變量(局部變量) 只能在該函數(shù)的范圍內(nèi)使用。
            C++ 的全局常量只有靜態(tài)連接性能。這不同于C,如果試圖在C++的
            多個(gè)文件內(nèi)使用全局變量也會(huì)產(chǎn)生LNK2001錯(cuò)誤。一種解決的方法是需要時(shí)在
            頭文件中加入該常量的初始化代碼,并在.CPP文件中包含該頭文件;另一種
            方法是使用時(shí)給該變量賦以常數(shù)。
            二.由于編譯和鏈接的設(shè)置而造成的LNK2001
            1.如果編譯時(shí)使用的是/NOD(/NODEFAULTLIB)選項(xiàng),程序所需要的運(yùn)行
            庫(kù)和MFC庫(kù)在連接時(shí)由編譯器寫入目標(biāo)文件模塊, 但除非在文件中明確包含
            這些庫(kù)名,否則這些庫(kù)不會(huì)被鏈接進(jìn)工程文件。在這種情況下使用/NOD將導(dǎo)
            致錯(cuò)誤LNK2001。
            2.如果沒有為wWinMainCRTStartup設(shè)定程序入口,在使用Unicode和MFC
            時(shí)將得到“unresolved external on _WinMain@16”的LNK2001錯(cuò)誤信息。
            3.使用/MD選項(xiàng)編譯時(shí),既然所有的運(yùn)行庫(kù)都被保留在動(dòng)態(tài)鏈接庫(kù)之內(nèi),
            源文件中對(duì)“func”的引用,在目標(biāo)文件里即對(duì)“__imp__func” 的引用。
            如果試圖使用靜態(tài)庫(kù)LIBC.LIB或LIBCMT.LIB進(jìn)行連接,將在__imp__func上發(fā)
            生LNK2001;如果不使用/MD選項(xiàng)編譯,在使用MSVCxx.LIB連接時(shí)也會(huì)發(fā)生LNK2001。
            4.使用/ML選項(xiàng)編譯時(shí),如用LIBCMT.LIB鏈接會(huì)在_errno上發(fā)生LNK2001。
            5.當(dāng)編譯調(diào)試版的應(yīng)用程序時(shí),如果采用發(fā)行版模態(tài)庫(kù)進(jìn)行連接也會(huì)產(chǎn)
            生LNK2001;同樣,使用調(diào)試版模態(tài)庫(kù)連接發(fā)行版應(yīng)用程序時(shí)也會(huì)產(chǎn)生相同的
            問(wèn)題。
            6.不同版本的庫(kù)和編譯器的混合使用也能產(chǎn)生問(wèn)題,因?yàn)樾掳娴膸?kù)里可
            能包含早先的版本沒有的符號(hào)和說(shuō)明。
            7.在不同的模塊使用內(nèi)聯(lián)和非內(nèi)聯(lián)的編譯選項(xiàng)能夠?qū)е翷NK2001。如果
            創(chuàng)建C++庫(kù)時(shí)打開了函數(shù)內(nèi)聯(lián)(/Ob1或/Ob2),但是在描述該函數(shù)的相應(yīng)頭
            文件里卻關(guān)閉了函數(shù)內(nèi)聯(lián)(沒有inline關(guān)鍵字),這時(shí)將得到該錯(cuò)誤信息。
            為避免該問(wèn)題的發(fā)生,應(yīng)該在相應(yīng)的頭文件中用inline關(guān)鍵字標(biāo)志內(nèi)聯(lián)函數(shù)。
            8.不正確的/SUBSYSTEM或/ENTRY設(shè)置也能導(dǎo)致LNK2001。
            其實(shí),產(chǎn)生LNK2001的原因還有很多,以上的原因只是一部分而已,對(duì)初
            學(xué)者來(lái)說(shuō)這些就夠理解一陣子了。但是,分析錯(cuò)誤原因的目的是為了避免錯(cuò)
            誤的發(fā)生。LNK2001錯(cuò)誤雖然比較困難,但是只要注意到了上述問(wèn)題,還是能
            夠避免和予以解決的。
            posted on 2007-01-09 17:53 小不懂^_^ 閱讀(1073) 評(píng)論(2)  編輯 收藏 引用

            評(píng)論

            # re: 編譯VC++時(shí)出現(xiàn)的LINK2001的錯(cuò)誤及解決 2007-01-10 11:19 pengkuny
            精彩  回復(fù)  更多評(píng)論
              

            # re: 編譯VC++時(shí)出現(xiàn)的LINK2001的錯(cuò)誤及解決 2007-06-07 23:12 星夢(mèng)情緣
            好貼,頂頂  回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            久久久久亚洲av无码专区喷水| 青青草国产精品久久久久| 日本三级久久网| 国产情侣久久久久aⅴ免费| 国产欧美一区二区久久| 精品久久久久国产免费 | 久久国产精品成人免费| 人妻久久久一区二区三区| 精品久久久久久无码免费| 久久99精品九九九久久婷婷| 久久久久久亚洲精品不卡| 久久久久久国产精品无码超碰| 亚洲中文久久精品无码| 品成人欧美大片久久国产欧美| 性做久久久久久久久浪潮| 伊人久久综在合线亚洲2019 | 久久无码精品一区二区三区| 熟妇人妻久久中文字幕| 久久人人爽人人爽人人片AV麻豆 | 88久久精品无码一区二区毛片| 伊人色综合久久| 色天使久久综合网天天| 久久青草国产精品一区| 久久久久久亚洲精品不卡| 一本色综合网久久| 久久r热这里有精品视频| 综合久久精品色| 久久91精品综合国产首页| 人人狠狠综合久久亚洲| 久久精品人人做人人妻人人玩| 国内精品久久久久久久久电影网 | 国内精品久久久久久久久电影网 | 久久精品国产免费一区| 亚洲欧美另类日本久久国产真实乱对白 | 亚洲精品99久久久久中文字幕 | 99久久99久久精品国产| 久久人人爽人人人人爽AV| 久久涩综合| 久久777国产线看观看精品| 老男人久久青草av高清| 色婷婷综合久久久久中文一区二区 |