在VS中能正常编译运行,但在命令行下却出现无法解析的外部命令??

Bone2 2010-01-06 07:54:48
同样的几个程序,在VS中新建了一个工程,能编译运行通过,但却在命令行下运行出现“error LNK2019 无法解析的外部符号”错误,我确信我已经把用到的库文件和路径都加到系统变量中了。
这是我的cpp文件代码,它对一个简单的Add类进行测试:
#include <gtest/gtest.h>
#include"Add.h"

TEST(AddTest, HandleNoneZeroInput)
{
Add a;
EXPECT_EQ(4, a.add(4, 10));
EXPECT_EQ(6, a.add(2, 4));

}
int main(int argc,char* argv[])
{
testing::InitGoogleTest(&argc,argv);
return RUN_ALL_TESTS();
}

求救!!
...全文
440 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
Bone2 2010-01-07
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 arong1234 的回复:]
你链接的命令行是什么?
看看你vs里的工程设置,其中libraries列表中的所有库是不是都添在你link的命令行中了?

[/Quote]
工程设置里加了一个linker是gtestd.lib,就加上 #pragma comment(lib, "gtestd.lib")
又出新问题了
gtestd.lib(gtest.obj) : warning LNK4075: 忽略“/EDITANDCONTINUE”(由于“/OPT:ICF
”规范)
LIBCMTD.lib(dbgheap.obj) : error LNK2005: __heap_alloc 已经在 LIBCMT.lib(malloc.
obj) 中定义
LIBCMTD.lib(dbgheap.obj) : error LNK2005: __recalloc 已经在 LIBCMT.lib(recalloc.
obj) 中定义
LIBCMTD.lib(dbgheap.obj) : error LNK2005: __msize 已经在 LIBCMT.lib(msize.obj)
中定义
LIBCMTD.lib(malloc.obj) : error LNK2005: _V6_HeapAlloc 已经在 LIBCMT.lib(malloc.
obj) 中定义


这是为何
arong1234 2010-01-07
  • 打赏
  • 举报
回复
你lib拷贝到路径是不够的,你必须明确告诉link程序你需要哪个库。link不会把lib路径下所有的库都链接的。你如果不告诉它,它就啥也不链接,必然出现你这个问题。


[Quote=引用 4 楼 bone2 的回复:]
没有 直接复制到的  ..\Windows\v6.0A\Lib下了  环境变量也都改了 不知道为什么还是不行?
[/Quote]
arong1234 2010-01-07
  • 打赏
  • 举报
回复
你链接的命令行是什么?
看看你vs里的工程设置,其中libraries列表中的所有库是不是都添在你link的命令行中了?
Bone2 2010-01-07
  • 打赏
  • 举报
回复
恩 我截取几个错误上来 让大家帮我分析下看
gtest.obj : error LNK2019: 无法解析的外部符号 "public: __thiscall testing::inter
nal::AssertHelper::~AssertHelper(void)" (??1AssertHelper@internal@testing@@QAE@X
Z),该符号在函数 "private: virtual void __thiscall AddTest_HandleNoneZeroInput_T
est::TestBody(void)" (?TestBody@AddTest_HandleNoneZeroInput_Test@@EAEXXZ) 中被引

gtest.obj : error LNK2019: 无法解析的外部符号 "public: void __thiscall testing::
internal::AssertHelper::operator=(class testing::Message const &)const " (??4Ass
ertHelper@internal@testing@@QBEXABVMessage@2@@Z),该符号在函数 "private: virtual
void __thiscall AddTest_HandleNoneZeroInput_Test::TestBody(void)" (?TestBody@Ad
dTest_HandleNoneZeroInput_Test@@EAEXXZ) 中被引用
gtest.obj : error LNK2019: 无法解析的外部符号 "public: __thiscall testing::inter
nal::AssertHelper::AssertHelper(enum testing::TestPartResult::Type,char const *,
int,char const *)" (??0AssertHelper@internal@testing@@QAE@W4Type@TestPartResult@
2@PBDH1@Z),该符号在函数 "private: virtual void __thiscall AddTest_HandleNoneZer
oInput_Test::TestBody(void)" (?TestBody@AddTest_HandleNoneZeroInput_Test@@EAEXXZ
) 中被引用
gtest.obj : error LNK2019: 无法解析的外部符号 "public: int __thiscall Add::add(i
nt,int)" (?add@Add@@QAEHHH@Z),该符号在函数 "private: virtual void __thiscall Ad
dTest_HandleNoneZeroInput_Test::TestBody(void)" (?TestBody@AddTest_HandleNoneZer
oInput_Test@@EAEXXZ) 中被引用
gtest.obj : error LNK2019: 无法解析的外部符号 "public: int __thiscall testing::U
nitTest::Run(void)" (?Run@UnitTest@testing@@QAEHXZ),该符号在函数 _main 中被引用
arong1234 2010-01-07
  • 打赏
  • 举报
回复
跟路径无关,因为如果那样,就会说文件不存在错误

我觉得首先要看是什么符号找不到,根据这个信息再判断是哪个库没link进去
Bone2 2010-01-07
  • 打赏
  • 举报
回复
没有 直接复制到的 ..\Windows\v6.0A\Lib下了 环境变量也都改了 不知道为什么还是不行?
liyelun 2010-01-07
  • 打赏
  • 举报
回复
有时候,头文件之间相互包含,会导致各种混乱,好像也会引起错误
但是引起的是不是这种错误记不清了...
Bone2 2010-01-07
  • 打赏
  • 举报
回复
我测试函数cpp 居然不能解析到 目标函数cpp中的函数方法实现?! 很是奇怪啊, 在命令行下会出现这样的问题么? 怎么解决啊??
Bone2 2010-01-07
  • 打赏
  • 举报
回复
现在解决一些问题了 , MTd 一下后剩下这个错误
gtest.obj : error LNK2019: 无法解析的外部符号 "public: int __thiscall Add::add(i
nt,int)" (?add@Add@@QAEHHH@Z),该符号在函数 "private: virtual void __thiscall Ad
dTest_HandleNoneZeroInput_Test::TestBody(void)" (?TestBody@AddTest_HandleNoneZer
oInput_Test@@EAEXXZ) 中被引用
gtest.exe : fatal error LNK1120: 1 个无法解析的外部命令

这是差的哪个lib啊 求救!!
liyelun 2010-01-06
  • 打赏
  • 举报
回复
相应地lib文件是不是复制到了工作目录下?
Bone2 2010-01-06
  • 打赏
  • 举报
回复
就是添加如#pragma comment(lib, "reg.lib")这样的预编译命令么
我刚才加了一个lib文件 还是有错误啊 应该加哪些lib进去??
sunlin7 2010-01-06
  • 打赏
  • 举报
回复
link的时候加上user32.lib kernel32.lib等这样的库文件名.

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧