Externally linked libcurl headers are available for ProjectName_SharedCode, but not ProjectName_VST

Libcurl makes me want to pull my hair out!

I’ve followed many threads here about linking libcurl to my VS2017 project through the projucer, and I’ve gotten pretty far, but now I’m coming across an issue that I haven’t seen discussed here.

My VS2017 solution contains 2 projects: EQIP_SharedCode and EQIP_VST (Generated by the projucer). I can see the curl.h file under the “External Dependencies” folder in EQIP_SharedCode, so I assume that’s why my #include <curl/curl.h> statement works in compilation. However, i get errors in the linking phase:

LNK2001 unresolved external symbol curl_easy_init - Project: EQIP_VST

The EQIP_VST project doesn’t include curl.h in “External Dependencies”, so I assume that’s why it can’t link. Shouldn’t the projucer make sure the headers are included in all projects of the VS2017 solution? What’s my next move?

Just FYI - I’ve already defined the correct Header Search Path and Extra Library Search Paths for the configuration in the projucer, as well as CURL_STATICLIB in the preprocessor definitions. (Thanks to the forum discussions here, I was able to figure this out! I feel like there needs to be a stickied libcurl HOWTO or something…)

Your issue has nothing to do with headers. Headers and header search paths are only involved at compilation time, and here, as you said, you are getting errors in the linking phase.

You need to tell the linker that you want to link against libcurl. This is done by adding libcurl to the setting “External libraries to link”, and adding the path to libcurl.lib to the setting “Extra library search paths” (both in Projucer).

Thanks for the quick reply!

I do have libcurl in “External libraries to link”, like so:


And I have “Extra library search paths” set to:

That should do it, no?

You didn’t read the documentation of “External libraries to link”. It says:

You should not add any platform specific decoration to these names.

This means that you have to write libcurl_a only.

The path is covered by “Extra library search paths” anyway.

Aha, that makes sense -

I did that, but on linking it now says “cannot open libcurl_a.obj”. When I ran the cmake command for libcurl, it didn’t output any .obj files, so I don’t know what to do here. I just tried setting “External Libraries to link” to libcurl_a.lib, but then it just gives me the same linking errors as before.

Could you tell me where you downloaded the curl binaries from? I would like to try myself.


I downloaded the latest source, used the Developer Commant Prompt for VS 2017 program to navigate into the winbuild directory, and ran the command nmake /f Makefile.vc mode=static. The libcurl_a.lib file gets outputted to the “builds” folder.

Thanks for your help, much appreciated!

I added a dummy call to curl_easy_init() in the “Main.cpp” of the HelloWorld project and I got it compiling and linking after doing the following:

  • Add D:\dev\curl-7.54.1\builds\libcurl-vc-x86-release-static-ipv6-sspi-winssl\include to “Header search paths”
  • Add CURL_STATICLIB to “Extra Preprocessor Definitions”
  • Add libcurl_a.lib to “External libraries to link” (this contradicts what I said in a precedent post, sorry)
  • Add D:\dev\curl-7.54.1\builds\libcurl-vc-x86-release-static-ipv6-sspi-winssl\lib to “Extra library search paths”
  • Change “Runtime Library” to “Use DLL runtime”
  • Change “Architecture” to “32-bit”

I guess there is some incompatibility between how you are building your VST plugin and how libcurl was built. Make sure that the Architecture (x86 vs. x64 in curl, 32-bit vs. x64 in Projucer) and the Runtime Library (RTLIBCFG=dll vs. RTLIBCFG=static in curl, DLL runtime vs. static runtime in Projucer) match between your project and libcurl.


Aha, that did it! Libcurl was x86 and my plugin was x64. Fixing the mismatch made it compile just fine. Thanks for the help!

1 Like