亚洲精品无码久久,久久久无码精品亚洲日韩按摩,精品无码av无码免费专区

第一篇：visual studio 6.0 link 2001常見錯誤解決總結

visual studio 6.0 link 2001常見錯誤解決總結

第一：

nafxcwd.lib(appcore.obj): error LNK2001: unresolved external symbol ___argv

nafxcwd.lib(appcore.obj): error LNK2001: unresolved external symbol ___argc

nafxcwd.lib(timecore.obj): error LNK2001: unresolved external symbol __mbctype

nafxcwd.lib(apphelp.obj): error LNK2001: unresolved external symbol __mbctype

nafxcwd.lib(filelist.obj): error LNK2001: unresolved external symbol __mbctype

解決辦法：

PROJECT->SETING->C/C++->PREPROCESSOR->定義 _AFXDLL

第二：

解決外部符號錯誤:_main,_WinMain@16,__beginthreadex

在創建MFC項目時, 不使用MFC AppWizard向導, 如果沒有設置好項目參數, 就會在編譯時產生很多連接錯誤, 如error LNK2001錯誤, 典型的錯誤提示有:

libcmtd.lib(crt0.obj): error LNK2001: unresolved external symbol _main

LIBCD.lib(wincrt0.obj): error LNK2001: unresolved external symbol _WinMain@16

1.Windows子系統設置錯誤, 提示:

libcmtd.lib(crt0.obj): error LNK2001: unresolved external symbol _main

Windows項目要使用Windows子系統, 而不是Console, 可以這樣設置:

[Project]--> [Settings]--> 選擇“Link”屬性頁,在Project Options中將/subsystem:console改成/subsystem:windows

2.Console子系統設置錯誤, 提示:

LIBCD.lib(wincrt0.obj): error LNK2001: unresolved external symbol _WinMain@16

控制臺項目要使用Console子系統, 而不是Windows, 設置:

[Project]--> [Settings]--> 選擇“Link”屬性頁,在Project Options中將/subsystem:windows改成/subsystem:console

3.程序入口設置錯誤, 提示:

msvcrtd.lib(crtexew.obj): error LNK2001: unresolved external symbol _WinMain@16

通常, MFC項目的程序入口函數是WinMain, 如果編譯項目的Unicode版本, 程序入口必須改為wWinMainCRTStartup, 所以需要重新設置程序入口:

[Project]--> [Settings]--> 選擇“Link”屬性頁,在Category中選擇Output,再在Entry-point symbol中填入wWinMainCRTStartup, 即可

4.線程運行時庫設置錯誤, 提示:

nafxcwd.lib(thrdcore.obj): error LNK2001: unresolved external symbol __beginthreadexnafxcwd.lib(thrdcore.obj): error LNK2001: unresolved external symbol __endthreadex

這是因為MFC要使用多線程時庫, 需要更改設置:

[Project]--> [Settings]--> 選擇“C/C++”屬性頁,在Category中選擇Code Generation,再在Use run-time library中選擇Debug Multithreaded或者multithreaded

其中,Single-Threaded 單線程靜態鏈接庫(release版本)

Multithreaded 多線程靜態鏈接庫(release版本)

multithreaded DLL 多線程動態鏈接庫(release版本)

Debug Single-Threaded 單線程靜態鏈接庫(debug版本)

Debug Multithreaded 多線程靜態鏈接庫(debug版本)

Debug Multithreaded DLL 多線程動態鏈接庫(debug版本)

單線程: 不需要多線程調用時, 多用在DOS環境下

多線程: 可以并發運行

靜態庫: 直接將庫與程序Link, 可以脫離MFC庫運行

動態庫: 需要相應的DLL動態庫, 程序才能運行

release版本: 正式發布時使用

debug版本: 調試階段使用

初學者在學習VC++的過程中，遇到的LNK2001錯誤的錯誤消息主要為：

unresolved external symbol “symbol”（不確定的外部“符號”）。

如果連接程序不能在所有的庫和目標文件內找到所引用的函數、變量或標簽，將產生此錯誤消息。一般來說，發生錯誤的原因有兩個：一是所引用的函數、變量不存在、拼寫不正確或者使用錯誤；其次可能使用了不同版本的連接庫。

以下是可能產生LNK2001錯誤的原因：

一．由于編碼錯誤導致的LNK200

11．不相匹配的程序代碼或模塊定義(.DEF)文件能導致LNK2001。例如, 如果在C++源文件內聲明了一變量“var1”，卻試圖在另一文件內以變量“VAR1”訪問該變量,將發生該錯誤。

2．如果使用的內聯函數是在.CPP文件內定義的，而不是在頭文件內定義將導致LNK2001錯誤。

3．調用函數時如果所用的參數類型同函數聲明時的類型不符將會產生LNK2001。

4．試圖從基類的構造函數或析構函數中調用虛擬函數時將會導致LNK2001。

5．要注意函數和變量的可公用性，只有全局變量、函數是可公用的。靜態函數和靜態變量具有相同的使用范圍限制。當試圖從文件外部訪問任何沒有在該文件內聲明的靜態變量時將導致編譯錯誤或LNK2001。

函數內聲明的變量(局部變量)只能在該函數的范圍內使用。

C++ 的全局常量只有靜態連接性能。這不同于C，如果試圖在C++的多個文件內使用全局變量也會產生LNK2001錯誤。一種解決的方法是需要時在頭文件中加入該常量的初始化代碼，并在.CPP文件中包含該頭文件；另一種方法是使用時給該變量賦以常數。

二．由于編譯和鏈接的設置而造成的LNK2001

1．如果編譯時使用的是/NOD(/NODEFAULTLIB)選項，程序所需要的運行庫和MFC庫在連接時由編譯器寫入目標文件模塊，但除非在文件中明確包含這些庫名，否則這些庫不會被鏈接進工程文件。在這種情況下使用/NOD將導致錯誤LNK2001。

2．如果沒有為wWinMainCRTStartup設定程序入口，在使用Unicode和MFC時將得到“unresolved external on _WinMain@16”的LNK2001錯誤信息。

3．使用/MD選項編譯時,既然所有的運行庫都被保留在動態鏈接庫之內，源文件中對“func”的引用，在目標文件里即對“__imp__func” 的引用。如果試圖使用靜態庫LIBC.LIB或LIBCMT.LIB進行連接，將在__imp__func上發生LNK2001；如果不使用/MD選項編譯，在使用MSVCxx.LIB連接時也會發生LNK2001。

4．使用/ML選項編譯時，如用LIBCMT.LIB鏈接會在_errno上發生LNK2001。

5．當編譯調試版的應用程序時，如果采用發行版模態庫進行連接也會產生LNK2001；同樣，使用調試版模態庫連接發行版應用程序時也會產生相同的問題。

6．不同版本的庫和編譯器的混合使用也能產生問題，因為新版的庫里可能包含早先的版本沒有的符號和說明。

編程時打開了函數內聯（/Ob1或/Ob2)，但是在描述該函數的相應頭文件里卻關閉了函數內聯（沒有inline關鍵字），這時將得到該錯誤信息。為避免該問題的發生，應該在相應的頭文件中用inline關鍵字標志內聯函數。

8．不正確的/SUBSYSTEM或/ENTRY設置也能導致LNK2001。

LINK : fatal error LNK1117: syntax error in option “subsystem:windows/incremental:yes” 解決方法：刪掉incremental:yes

vc編譯報錯 unresolved external symbol __imp__PlaySoundA@12 解決辦法添加Winmm.lib和頭文件中包含 Mmsystem.h

選擇“project”->“setting”->“link”->“Object/librarymodules”然后添加“Winmm.lib”就可以了。

第二篇：鋼筋常見錯誤總結（精選）

鋼筋常見錯誤

一、基礎常見錯誤

1、基礎梁接頭位置不對，按樓層框架梁接頭位置設置，且沒有錯開（基礎梁與框架梁的受力正好相反，接頭亦然）。

2、筏板鋼筋接頭在施工縫處預留長度不夠，且接頭沒錯開。

3、基礎馬凳擺放錯誤，如果換一方向，每一排馬凳可省一固定用通長鋼筋。或者，馬凳上通長鋼筋利用筏板上部同方向縱筋。

4、筏板面積較大，卻仍按50%接頭百分率，未按25%百分率接頭，導致鋼筋接頭浪費。

5、底板縱筋接頭長度有的太長，超過一個搭接長度，有的則太短，不能滿足規范所要求的長度。底板通長筋沒綁扎成平行直線，導致同截面鋼筋根數不同。

6、承臺按規范是不縮減的，設計“優化”按獨立基礎構造搞成縮減，這屬于設計的偷工減料。

7、筏板封邊構造沒按規范和設計，擅自設置筏板上下縱筋彎折長度。

8、筏板縱筋接頭設置在后澆帶內（縱筋接頭不宜設置在后澆帶位置）。

9、接樁鋼筋并在一塊。

二、柱常見錯誤

1、頂層邊柱均未設置彎折，11G101規定是當采用柱外搭接時，柱外側可不彎折，但柱內側鋼筋當梁高度小于錨固時均要求彎折。

2、頂層中柱彎折，頂層中柱縱筋如果在梁內滿足直錨就不需要彎折。

3、柱梁節點箍筋未設置或間距太大。柱梁節點是核心節點，是抗震的關鍵節點，寧可少放梁縱筋也不能省掉梁柱節點內的箍筋。

4、柱縱筋沒有長短交錯，這是鋼筋翻樣問題，對柱上下鋼筋根數發生變化時沒在下層調整豎向鋼筋長度，導致接頭未能錯開。

5、柱保護層未滿足最小保護層厚度。

6、有的暗柱很長，暗箍筋采用U形，增加鋼筋接頭，應該是封閉式箍筋，可節約鋼筋。

7、暗柱箍筋有內折角，這是不允許的。兩個箍筋相交或錨固形成的角度不屬于內折角。

8、無地下室柱加密從正負零以上H0/3，應該是從基礎頂面開始算起。

三、墻常見錯誤

1、墻水平筋（外側與內鍘）在同一位置搭接，沒有按接頭百分率錯開接頭。

2、墻水平筋接頭未設置在受力最小處。外墻外側水平鋼筋應位于跨中三分之一或墻高四分之一區域，外墻內側應位于支座及支座附近。

3、地下室外墻豎向鋼筋接頭位置錯誤，根據規范外墻外側豎向鋼筋應位于墻高中間的三分之一區域，外墻內側豎向縱筋應位于墻高根部的四分之一區域。

4、外墻外側鋼筋頂模，無保護層，外墻外側鋼筋露筋后果很嚴重，最終把整個外墻破壞掉。外墻外側是直接接觸泥土和水，保護層不少于40mm。

5、結構總說明未注明頂板是外墻的簡支承還是彈性嵌固支承，施工也沒按照其施工，外墻縱筋彎折按墻厚減保護層，不知施工依據什么，還是想當然。

6、墻縱向鋼筋搭接長度過長，直接按墻高度。墻封頂時墻豎向鋼筋應該是減去下面預留長度再加搭接長度。

7、墻拉筋綁扎不規范，要么間距不對，要么做法不對，如沒拉住墻水平筋，要么拉筋長度不對，施工時不是垂直拉而是斜拉。

四、梁常見錯誤

1、梁支座鋼筋包括第一排支座負筋伸入支座均為L0/4（設計問題）。

2、主次梁交接處，主梁兩側增加附加箍筋。主梁在次梁位置未布置正常箍筋，直接布三道附加箍筋。

3、梁底筋一般都未綁扎。工人的借口是綁不到，其實是完全可以綁到的，先把梁抬高，用鋼管支架固定，待梁上下鋼筋包括腰筋全部綁扎完成后再把梁落下去就是，這是簡單的施工工藝。不綁屬于偷工減料，不綁，梁鋼筋糾結在一塊，影響其受力。

4、梁拉鉤施工按一端90度，一端135度，應該都為135度，當然拉鉤兩端都加工成135度不好放，可以先一端加工成90度，待綁扎完后再用扳手彎成135度。

5、非抗扭的非框架梁下部縱筋伸入支座為錨固長度，平法要求12d，這完全是無謂的浪費。

6、梁洞口周圍未布置鋼筋。規范嚴禁在梁上開洞，但也不可避免要在梁上開洞，補救措施就是對洞口進行加強。

7、梁接頭沒有設置在受力較小處（上部縱筋為跨中三分之一區域），而是設在受力最大處，有的把梁上部鋼筋設在梁支座處或附近。

8、屋面梁上部縱筋彎曲內徑不符合規范，規范要求>6d,8d，不過，這個一般是做不到。

9、吊筋按次梁高度施工，應該是按主梁高度施工。

10、梁墊塊做法不對，墊塊強度不夠而粉碎，導致梁直接與模板接觸，露筋無疑；有的用橫筋直接支承在板上。

11、梁拉筋漏放或斜放，有的沒綁扎，起不到拉筋作用。

12、梁二排鋼筋位置不對，離梁頂距離過大，起不到受力作用。

13、梁上部鋼筋采用綁扎接頭卻未在接頭位置加密箍筋，按規范要求在接頭位置設置橫向箍筋，間距為min(5d,100)，實際是很難做到，如果按規范做，幾乎變成全加密。梁縱筋最好采用機械連接或焊接（非電渣壓力焊），這樣，就不需要對接頭進行箍筋加密了。

14、梁上部鋼筋間距過密，混凝土澆筑困難。

15、幾個方向梁相交重疊，梁上部鋼筋無保護層甚至超過梁高度，這種情況可以把次梁上部縱筋放在主梁上部縱筋之下解決之。

16、非框架梁是非抗震，其箍筋無需彎成135度，平直段也無需10d。如果非框架梁設計是按非抗震考慮，其箍筋的彎鉤可做成90度，平直段長度為5d。

五、板常見錯誤

1、板筋的搭接長度過長。

2、板上部鋼筋接頭位置錯誤，板上部鋼筋接頭應在跨中，卻設置在支座。

3、板接頭百分率50%。未按25%施工。

4、板下部縱筋伸入支座長度未按規范，按全支座施工，規范為max(5d,b/2)

5、板上部縱筋伸入支座La，實際施工不管支座有多寬均按伸入支座對邊彎折15 d，當支座寬度不能滿足錨固長度時才需要彎折15d，如果滿足且支座很寬，板上部鋼筋可以彎折，但彎折長度加在支座內平直段長度等于錨固長度即可，沒有必要一定但到支座外側，因視情況而定。

第三篇：SAT常見錯誤總結

文都國際教育官方網站：http:// 文都國際教育官方網站：http://www.tmdps.cn/

第四篇：Hadoop常見錯誤總結

Hadoop常見錯誤總結 2010-12-30 13:55 錯誤1：bin/hadoop dfs 不能正常啟動，持續提示：

INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:9000.Already tried 0 time(s).原因：由于 dfs 的部分文件默認保存在tmp文件夾，在系統重啟時被刪除。解決：修改core-site.xml 的 hadoop.tmp.dir配置文件路徑：/home/hadoop/tmp。

錯誤2：hadoop出現了一些問題。用$ bin/hadoop dfsadmin-report 測試的時候，發現dfs沒有加載。顯示如下：

Configured Capacity: 0(0 KB)Present Capacity: 0(0 KB)DFS Remaining: 0(0 KB)DFS Used: 0(0 KB)DFS Used%: ?% Under replicated blocks: 0 Blocks with corrupt replicas: 0 Missing blocks: 0 查看日志：

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /home/hadoop/data: namenode namespaceID = 2033006627;datanode namespaceID = 1589898341 經分析，是由于namenode namespaceID = 2033006627;和datanode namespaceID = 1589898341 不一致造成原因。

修改了namenode namespaceID = 1589898341 可以使用，但是重啟之后，又不可以用了。

最后解決方案：刪除hadoop用戶下的name文件夾，data文件夾，tmp文件夾，temp文件里的內容，然后重新執行namenode命令。重啟電腦之后，正常。

錯誤3：File /home/hadoop/tmp/mapred/system/jobtracker.info could only be replicated to 0 nodes, instead of 1 出現此錯誤，一般發生在datanode與namenode還沒有進行連接，就開始往hdfs系統上put數據了。稍等待一會，就可以了。

也可以使用：hadoop dfsadmin –report命令查看集群的狀態。錯誤4：

每次啟動總有部分datanade不能去全部啟動，查看日志文件，顯示為： ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.net.UnknownHostException: zgchen-ubutun: zgchen-ubutun at java.net.InetAddress.getLocalHost(InetAddress.java:1426)。分析：這是由于datanode 找不到服務host引起的。

解決：通過查找/etc/hostname 找到hostname；比如：ubuntu。然后找到/etc/hosts，添加：127.0.1.1 ubuntu 錯誤5：

java.lang.OutOfMemoryError: GC overhead limit exceeded 分析：這個是JDK6新添的錯誤類型。是發生在GC占用大量時間為釋放很小空間的時候發生的，是一種保護機制。解決方案是，關閉該功能，可以添加JVM的啟動參數來限制使用內存：-XX:-UseGCOverheadLimit 添加位置是：mapred-site.xml 里新增項：mapred.child.java.opts 內容：-XX:-UseGCOverheadLimit java.lang.OutOfMemoryError: Java heap space 出現這種異常，明顯是jvm內存不夠得原因，要修改所有的datanode的jvm內存大小。

Java-Xms1024m-Xmx4096m 一般jvm的最大內存使用應該為總內存大小的一半，我們使用的8G內存，所以設置為4096m，這一值可能依舊不是最優的值。（其實對于最好設置為真實物理內存大小的0.8）

錯誤6：Too many fetch-failures Answer: 出現這個問題主要是結點間的連通不夠全面。1)檢查、/etc/hosts 要求本機ip 對應服務器名

要求要包含所有的服務器ip + 服務器名 2)檢查.ssh/authorized_keys 要求包含所有服務器（包括其自身）的public key 錯誤7：處理速度特別的慢出現map很快但是reduce很慢而且反復出現 reduce=0% Answer: 結合第二點，然后修改可用內存大小。

conf/hadoop-env.sh 中的export HADOOP_HEAPSIZE=4000 錯誤8：能夠啟動datanode，但無法訪問，也無法結束的錯誤

在重新格式化一個新的分布式文件時，需要將你NameNode上所配置的dfs.name.dir這一namenode用來存放NameNode 持久存儲名字空間及事務日志的本地文件系統路徑刪除，同時將各DataNode上的dfs.data.dir的路徑 DataNode 存放塊數據的本地文件系統路徑的目錄也刪除。如本此配置就是在NameNode上刪除/home/hadoop/NameData，在DataNode上刪除/home/hadoop/DataNode1和/home/hadoop/DataNode2。這是因為Hadoop在格式化一個新的分布式文件系統時，每個存儲的名字空間都對應了建立時間的那個版本（可以查看/home/hadoop /NameData/current目錄下的VERSION文件，上面記錄了版本信息），在重新格式化新的分布式系統文件時，最好先刪除NameData 目錄。必須刪除各DataNode的dfs.data.dir。這樣才可以使namedode和datanode記錄的信息版本對應。

注意：刪除是個很危險的動作，不能確認的情況下不能刪除！做好刪除的文件等通通備份！

錯誤9：java.io.IOException: Could not obtain block: blk_***469_1100 file=/user/hive/warehouse/src_20100924_log/src_20100924_log 出現這種情況大多是結點斷了，沒有連接上。或者

mapred.tasktracker.map.tasks.maximum 的設置超過 cpu cores數目，導致出現獲取不到文件。

錯誤10：Task Id : attempt_201010291615_0001_m_000234_0, Status : FAILED Error: java.io.IOException: No space left on device Task Id : attempt_201010291615_0001_m_000240_0, Status : FAILED java.io.IOException: Spill failed 磁盤空間不夠，應該分析磁盤空間df-h 檢查是否還存在磁盤空間。錯誤11:Task Id : attempt_201011011336_0007_m_000001_0, Status : FAILED org.apache.hadoop.hbase.client.RegionOfflineException: region offline: lm，1288597709144 網上說，將/hbase刪除；重啟hbase后，可以正常應用了。但是我找不到/hbase目錄，只好自己重新刪除掉一些hadoop文件，重新生成文件管理系統。

還有一個可能是，配置錯了/hbase/conf/hbase-env.sh的HBASE_CLASSPATH，這個默認是不配置的，所以可以不配置。

錯誤12：org.apache.hadoop.hbase.TableNotFoundException: org.apache.hadoop.hbase.TableNotFoundException: lm 找不到表，hbase啟動了，檢查一下是否存在需要的Htable。