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.xiexiebang.com/

第四篇：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。