使用 libcurl 与 Visual C 的链接问题2005：“无法解析的外部符号 __imp__curl_easy_setopt”
我计划在我的项目中使用 libcurl。我已经下载了库源代码，将其构建并集成到一个小型 POC 应用程序中。我能够构建并运行应用程序，生成的 libcurl.dll 和 libcurl_imp.lib 文件没有任何问题。现在，当我在项目中集成相同的库时，我收到链接器错误。
6>foo.obj：错误 LNK2001：无法解析的外部符号 __imp__curl_easy_setopt
6>foo.obj：错误 LNK2001：无法解析的外部符号 __imp__curl_easy_perform
6>foo.obj：错误 LNK2001：无法解析的外部符号 __imp__curl_easy_cleanup 6
>foo.obj：错误 LNK2001：未解决的外部符号 __imp__curl_global_init
6>foo.obj ：错误 LNK2001：无法解析的外部符号 __imp__curl_easy_init
我已经研究并尝试了各种解决方法，例如添加 CURL_STATICLIB 定义，其他库，更改为/MT甚至将库复制到发布目录，但似乎没有任何效果。据我所知，我的步骤中方法 #1 和方法 #2 之间的唯一区别是 #1 是使用 libcurl.dll 的控制台应用程序，而在我的主项目中，这是另一个尝试链接到 libcurl.dll 的 dll。是否需要改变方法？我可以对两者使用相同生成的多线程 DLL /MD 文件（尝试过 /MT 也没有成功）吗？还有其他想法吗？
以下是链接器选项。
- - - - - - - - - - - - - - - - - - - - - - - - -在职的-------------------------------------------------
/输出：“C:\SampleFTP\Release\SampleFTP.exe”/增量：NO /NOLOGO /LIBPATH:"C:\SampleFTP\SampleFTP\Release" /MANIFEST /MANIFESTFILE:"Release\SampleFTP.exe.intermediate.manifest" /DEBUG /PDB:"c:\SampleFTP\release\SampleFTP.pdb" /子系统：控制台 /OPT:REF /OPT:ICF /LTCG /机器：X86 /错误报告：提示 libcurl_imp.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
----------- - - - - - - - - - - - - - - - - - - - 在职的 - - - - - - --------------------------------------
------------------------ ----------------------------------不工作-------------- ----------------------------------
/OUT:".......\nt\Win32\发布/foo__tests.dll“/增量：NO /NOLOGO /LIBPATH:"C:\FullLibPath\libcurl_libs" /LIBPATH:"......\nt\Win32\Release" /DLL /MANIFEST /MANIFESTFILE:".\foo__tests\Win32\Release\foo__tests.dll.intermediate.manifest" /DEBUG /PDB:".......\nt\Win32\Release/foo_tests.pdb" /OPT:REF /OPT:ICF /LTCG /IMPLIB:".......\nt\Win32\Release/foo_tests.lib" /机器：X86 /错误报告：提示 odbc32.lib odbccp32.lib util_process.lib wsock32.lib Version.lib libcurl_imp.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib库 odbccp32.lib “……\nt\win32\release\otherlib1.lib” “......\nt\win32\release\otherlib2.lib”
-------------------------------- --------------不工作------------------------------------ --------------
I am planning to use libcurl in my project. I had downloaded the library source,built and integrated it in a small POC application. I am able to build and run the application without any issues with the generated libcurl.dll and libcurl_imp.lib files. Now when I integrate the same library in my project I am getting linker errors.
6>foo.obj : error LNK2001: unresolved external symbol __imp__curl_easy_setopt
6>foo.obj : error LNK2001: unresolved external symbol __imp__curl_easy_perform
6>foo.obj : error LNK2001: unresolved external symbol __imp__curl_easy_cleanup
6>foo.obj : error LNK2001: unresolved external symbol __imp__curl_global_init
6>foo.obj : error LNK2001: unresolved external symbol __imp__curl_easy_init
I have researched and tried all manners of workarounds like adding CURL_STATICLIB definitions , additional libraries , changing to /MT even copying the libs to the release directory but nothing seems to work. As far as I can see the only difference between approach #1 and #2 in my steps are #1 is an console application using the libcurl.dll while in my main project this is another dll which is trying to link to libcurl.dll.. Would that necessitate any change in approach? Can I use the same generated multi threaded DLL /MD file for both(Tried /MT also with no success)? Any other ideas?
Following are the linker options.
-------------------------------------------------Working-------------------------------------------------
/OUT:"C:\SampleFTP\Release\SampleFTP.exe" /INCREMENTAL:NO /NOLOGO
/LIBPATH:"C:\SampleFTP\SampleFTP\Release"
/MANIFEST /MANIFESTFILE:"Release\SampleFTP.exe.intermediate.manifest"
/DEBUG /PDB:"c:\SampleFTP\release\SampleFTP.pdb"
/SUBSYSTEM:CONSOLE
/OPT:REF /OPT:ICF /LTCG
/MACHINE:X86
/ERRORREPORT:PROMPT
libcurl_imp.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
-------------------------------------------------Working-------------------------------------------------
----------------------------------------------NotWorking-------------------------------------------------
/OUT:".......\nt\Win32\Release/foo__tests.dll" /INCREMENTAL:NO /NOLOGO
/LIBPATH:"C:\FullLibPath\libcurl_libs"
/LIBPATH:"......\nt\Win32\Release"
/DLL
/MANIFEST /MANIFESTFILE:".\foo__tests\Win32\Release\foo__tests.dll.intermediate.manifest" /DEBUG /PDB:".......\nt\Win32\Release/foo_tests.pdb"
/OPT:REF /OPT:ICF /LTCG
/IMPLIB:".......\nt\Win32\Release/foo_tests.lib"
/MACHINE:X86
/ERRORREPORT:PROMPT
odbc32.lib odbccp32.lib util_process.lib wsock32.lib Version.lib libcurl_imp.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
"......\nt\win32\release\otherlib1.lib"
"......\nt\win32\release\otherlib2.lib"
----------------------------------------------NotWorking-------------------------------------------------
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你运行命令了吗？
根据 --libs 的结果，我可以找到如何链接我的应用程序。
did you run the commands
With the results from --libs i could find how to link my application.
好吧......这令人尴尬......我已经设法解决了这个问题，正如你可能猜到的那样，它与 libcurl 无关......基本上链接到 libcurl 的文件是多个项目的一部分。因此，虽然我在第一个项目中正确定义了库，但在其他项目中却没有正确定义库。并且构建日志一个接一个地显示项目（成功/失败消息），只有在与我的项目一起完成时我才能注意到问题高级...总而言之，这是一次令人谦卑的经历..
吸取的教训（对于未来的游客来说）将是
- Libcurl 是一个成熟的产品，不太可能抄袭基本捆绑
- 如果您要使用 windows .dll，唯一需要的是
1）下载源码。打开 soln 文件。构建（作为发布 dll）。
2) 包括curl 库的附加头路径。
3) 链接时包含 .lib 文件作为依赖项。
4）开始进行curl调用（包括源代码中的curl标头）
，你应该可以开始了。首先（除了主页上的优秀存储库）我在这里找到了一个很好的教程...
http://www.luckyspin.org/?p=28
Ok...This embrassing....I had managed to resolve the issue and as you might guess it has nothing to do with libcurl..Basically the file which is linking to libcurl is part of multiple projects. So while I have defined the libs correctly in the first project, I have not in the others..And the build log shows the projects(success/failure messages) one after another and I could notice the problem only while going through togeather with my senior...All in all a humbling experience..
Lesson learnt(for future visitors here) would be
- Libcurl is a mature product and is unlikely to crib for basic bundling
- Only thing necessary if you are going to use windows .dll would be
1) Download source. Open soln file. Build(as release dll).
2) Include additional header path for curl libraries.
3) Include .lib file as a dependency while linking.
4) Start making curl calls (including ther curl headers in source)
and you should be good to go. For starting off(other than the excellent repository at the home page) I have fount a good tutorial here...
http://www.luckyspin.org/?p=28
我同意用户88595。此外，我们可能需要注意以下事项（根据经验）。
如果您的项目中有一些共享库：
假设您有一个 Visual Studio 解决方案
“A”是一个共享库项目
“B”是目标可执行项目（大多数情况下是启动项目）。
因此，您需要真正了解谁实际上在调用 libcurl.lib 的 API，
如果它们在“A”中被调用，您需要转到项目“A”的“librarian”属性，然后在那里添加 libcurl.lib 依赖项。另外，添加 lib 路径。
我犯了一个错误，将依赖项添加到“链接器”属性并将库路径添加到“B”，这导致了同样的问题。
关于 LDAP 的一些其他链接器错误：
解决本节中提到的链接器错误后，您将收到更多有关 LDAP 的错误，要解决此问题，请在“B”链接器依赖项下添加 wldap32.lib。
一切顺利，
阿琼
I agree to user88595. Additionally, we may need to look out for the following things(out of experience).
This is if you have some shared library in your project:
Say you have a Visual Studio solution with
"A" is a shared library project
"B" is the target executable project(most cases the startup project).
So, you need to really see who is actually calling the API's of libcurl.lib,
it they are being called within "A", you need to go to the "librarian" property of the project "A" and then add libcurl.lib dependency there. Also, add the lib paths.
I had done a mistake of adding the dependency to the "linker" property and the lib paths to "B", which caused this same problem.
Some additional linker errors w.r.t LDAP:
Once you resolve the linker errors mentioned in this section, you will get some more errors with respect to LDAP, to resolve this add wldap32.lib under the linker dependancy of "B".
All the best,
Arjun