Hi, first time posting here. I’m trying to build the C++ demo for the ArduCam USB 3.0 Camera Shield Plus but I can’t get it to compile. Some background on my setup:
Hardware: ArduCam USB 3.0 Camera Shield Plus
Camera: OV5647 (B0033)
Host: Windows, Visual Studio 2022, CMake
The C++ demo (GitHub - ArduCAM/ArduCAM_USB_Camera_Shield_Cpp_Demo · GitHub) is a different story. I tried compiling it via CMake and I also tried opening the project in Visual Studio 2022. Both attempts fail with what look like linker errors about two undefined functions: ArduCam_registerCtrls() and ArduCam_setCtrl().
Neither one appears in the ArduCamLib.h that ships with the demo repo, and they don’t seem to be in ArduCamLib.lib either.
Also, a separate question while I’m here: with a resolution of 640x480, can this setup process grayscale images at 16-bit over MIPI (CSI-2) in parallel? Is there a config file for that? If not, could one be generated for this application?
On the build failure, a couple of things would really help:
The full linker error output (the LNK2019 lines plus the LNK1120 summary).
Which .cpp file is calling ArduCam_registerCtrls() and ArduCam_setCtrl().
Can you run dumpbin /exports ArduCamLib.lib and paste the symbol list? That tells us what the shipped import library actually exports.
Which configuration you’re building (x64 vs Win32, Debug vs Release) and how you’re pointing the project at ArduCamLib.lib/.dll.
On the 16-bit grayscale / 640x480 CSI-2 question, let me check that with the team separately — I don’t want to give you a wrong answer on the format support.
Sure, here’s the build output (trimmed to the relevant bits):
1>------ Build started: Project: ArduCAM_Demo, Configuration: Release x64 ------
1> main.cpp
1>main.obj : error LNK2019: unresolved external symbol "int __cdecl ArduCam_registerCtrls(void *,struct Control *,unsigned int)" (?ArduCam_registerCtrls@@YAHPEAXPEAUControl@@I@Z) referenced in function main
1>main.obj : error LNK2019: unresolved external symbol "int __cdecl ArduCam_setCtrl(void *,char const *,__int64)" (?ArduCam_setCtrl@@YAHPEAXPEBD_J@Z) referenced in function main
1>C:\...\ArduCAM_Demo.exe : fatal error LNK1120: 2 unresolved externals
The declarations I was expecting look like this:
int ArduCam_registerCtrls(ArduCamHandle useHandle, Control *controls, Uint32 controls_length);
int ArduCam_setCtrl(ArduCamHandle useHandle, const char *func_name, Int64 val);
They are not in the ArduCamLib.h or ArduCamLib.lib included with the C++ demo repo. I ran dumpbin /exports on the shipped ArduCamLib.lib and I don’t see either of those two symbols in the output — that’s why I think the linker can’t resolve them.
Running Release x64, and the lib/dll are linked straight from the repo’s lib folder.
Thanks, that output matches what you described — two unresolved externals against the shipped import library.
A few quick checks before we go further:
Confirm the import lib matches the DLL and your platform. If ArduCamLib.lib is 32-bit (or Debug) and you’re building Release x64, you’d get exactly this kind of LNK2019.
Check the project properties under Linker > Input and make sure only one copy of ArduCamLib.lib is listed, and that the .lib path actually resolves.
Confirm the DLL next to the built exe is the same build as the .lib.
Also, could you confirm whether main.cpp in that repo even uses registerCtrls/setCtrl? It’s odd that the sample would reference functions the shipped headers don’t declare — that usually means the sample source and the bundled lib came from different points in time.
I checked all of that. It’s Release x64, and the lib path resolves. I only have one ArduCamLib.lib listed.
What I tried next: I found the same two functions in an ArduCamLib.h downloaded from a different repo (https://github.com/ArduCAM/ArduCAM_USB_Camera_Shield) and appended those declarations to the header file in the C++ demo. That made things worse instead of better — now I get redeclaration errors plus a pile of linker errors:
error C2084: function 'int ArduCam_registerCtrls(...)' already has a body
error C2084: function 'int ArduCam_setCtrl(...)' already has a body
LNK2005: already defined in ...
So the declarations from the other header don’t match what the shipped lib expects, and adding them just creates duplicate symbols.
Right, that confirms the theory. Those C2084/LNK2005 errors are the classic symptom of mixing headers and libraries from two different ArduCam packages — you end up with duplicate declarations and mismatched symbols, and the linker has no single consistent definition to bind to.
Please don’t keep patching the header, it’ll just snowball. Two suggestions:
Start from a completely fresh clone of the C++ demo repo into a clean directory, and build it as-is without editing anything, following the steps in the repo’s own instructions (README/GitHub page).
If it still fails, tell me the exact commit/branch you cloned, your CMake version, and your MSVC toolset version.
Also — one thing worth double-checking, since you ran the Python demo successfully: the two demos use different library packages. Make sure the Visual Studio project isn’t accidentally picking up a copy of ArduCamLib.h/.lib from the Python demo folder via an include path or PATH. That alone can produce the mismatch you’re seeing.
Ok, did a fresh clone into a clean folder, no edits at all, built straight per the README. Same two LNK2019 errors for ArduCam_registerCtrls and ArduCam_setCtrl. Nothing from the Python demo folder is on my include path or PATH — I checked that specifically.
At this point, would it be possible to get the C++ source code for the library files ArduCamLib.lib and ArduCamLib.dll? I think being able to see how those two functions are supposed to be declared and exported would let me fix this on my side. I’ve attached a screenshot of the build output so you can see exactly what I’m getting: https://cdn.arducam.com/forum/f9fc156d4985a28faeabcb928c395323/image003.png
Appreciate the screenshot and the clean-clone confirmation.
I went back and reproduced the C++ demo on my side by following the GitHub repo steps exactly, and it built and ran for me without hitting these undefined-symbol errors. I even re-checked the exports with dumpbin and the demo links cleanly. Because of that, I honestly can’t give you a specific debug suggestion for the exact error you’re hitting — I can’t reproduce it here, so I’d only be guessing.
Before I take this further: what exact commit/branch did your clone end up on, and what CMake and MSVC toolset versions are you on? If your clone is on a different revision than what I tested, that would explain the header/lib mismatch.
It’s the default branch, straight from the repo link, cloned today — I didn’t switch to any tag or older commit. CMake and Visual Studio 2022 are both current installs from this machine, nothing exotic.
I’m stuck on this. The lib I have clearly doesn’t export the two symbols the sample calls, and I can’t add them myself without breaking the build. Without the source for ArduCamLib.lib/.dll I don’t see how I can resolve the mismatch.
I asked the team about the library source, including the chief engineer. The answer is that the C++ library source code is not open — it isn’t something we can provide to customers, so I’m not able to send you the ArduCamLib.lib/.dll sources.
Combined with the fact that I can build and run the demo here following the GitHub steps, that leaves me without a concrete fix for the undefined-function/linker errors on your side. I’m not going to hand you a guess that might send you down another rabbit hole.
Understood on the source. Is there any other supported way to reach the camera module then? Python works for me, but I was really trying to get a C++ path going for my application.
Yes — for accessing the camera module, the supported route is the Upper Computer software. It talks to the camera directly and doesn’t depend on building the C++ demo yourself.
Quick summary of where this landed so anyone else reading the thread has the full picture:
The C++ demo fails to link because the sample references ArduCam_registerCtrls() and ArduCam_setCtrl(), which are not declared/exported by the shipped ArduCamLib.h / ArduCamLib.lib.
Copying those declarations in from a different ArduCamLib.h (from another ArduCam repo) causes duplicate declarations and symbols — C2084 / LNK2005 — so that workaround doesn’t work.
On our side the C++ demo builds and runs by following the GitHub steps, so we could not reproduce the undefined-symbol errors, and therefore can’t offer a debug suggestion for that specific failure.
The C++ library source (ArduCamLib.lib/.dll) is not open and cannot be provided to customers, so we can’t supply the code needed to fix the declaration/export mismatch from your side.
Recommended path for accessing the camera module in the meantime: use the Upper Computer software (link above).
Your other question about 640x480 16-bit grayscale over MIPI (CSI-2) and whether a config file exists for that is still open — I haven’t got a confirmed answer yet, and I’ll follow up in this thread once I do.
