1

I'm trying to use the Canon EDSDK (latest version, v3.6 as of writing) in a simple, C++, command-line program on macOS (Sierra 10.12.6). I wish to utilize a simple Makefile environment and the usual apple compiler tools (llvm-clang) and avoid Xcode or any other heavy-weight IDE. The samples included with the SDK are all Xcode centric so I've had to roll my own here.

At present, I am able to compile a program to init the SDK and list connected cameras. As soon as I execute any EDSDK command however, I am getting a dynamic linking error:

Error loading /Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG:  dlopen(/Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG, 262): no suitable image found
Did find: ... snip ... mach-o, but wrong architecture

The same error lists twice (both for DppCoreG). Upon examination, DppCoreG is compiled for 64bit architecture:

file /Library/Frameworks/..snip../DppCoreG
/Library/Frameworks/..snip../DppCoreG: Mach-O 64-bit bundle x86_64

However, there are other critical parts of the EDSDK that are compiled for 32bit architecture only:

file /...snip.../DPP.framework/DPP 
/...snip.../DPP.framework/DPP: Mach-O dynamically linked shared library i386

How do I resolve this? The path of least resistance so far is to compile to i386 architecture explicitly (and the documentation explicitly states EDSDK is not 64-bit compatible). All is well except this one dynamic linking error (and in fact everything I've tried so far, which is just listing connected cameras, seems to work okay) but it is something I'm sure I can't continue to ignore or allow to persist in a production version of this project.

Here's a minimal example to cause the DYLD error:

#include <EDSDK.h>
#include <EDSDKTypes.h>
#include <EDSDKErrors.h>

int main(int argc, char** argv) {
  EdsInitializeSDK();
  EdsTerminateSDK();
  return 0;
}

And probably more informative is the command to compile:

c++ -D __MACOS__ -g -arch i386 -I./deps/mac/include -framework DPP -framework EDSDK -o min min.cpp

I have the headers in the local include directory shown in the command and the frameworks installed under /Library/Frameworks.

Note that the c++ command is Apple LLVM version 8.1.0 (clang-802.0.42)

OllieBrown
  • 143
  • 8
  • Did you inspect the output binary with `otool` or `MachOView`? Seems the fat binary header contains 64bit architecture and the 32bit one (the only desired one). As a side note, bare in mind Apple will drop 32bit support in forthcoming MacOS , High Sierra will be the last one to support it with a warning. – Kamil.S Aug 11 '17 at 11:01
  • Yes, using otool I can observe that the majority of the binaries included with the EDSDK on Mac are 32bit but this one is 64bit (the DPPCoreG binary in the plugins folder). When I compile for 32bit architecture everything but this one dynamically loaded plugin works. It is Canon's library that is 32bit only so I don't have a choice as far as 32 vs 64 bit. Presumably if they continue to support this library (which I hope they will) they will upgrade it to be fully 64bit compatible before the successor to High Sierra comes around. – OllieBrown Aug 11 '17 at 21:31
  • I'm not sure if this up to date, but I found a sample project here: https://github.com/matthewepler/ofxCanon_test and it does contain DPP framework binary in 32bit. Perhaps you could try it. Basically you cannot mix 32bit and 64bit dependencies in a binary unless you would have both variants for each dependency resulting a 32/64bit fat binary (which is impossible in your case due to EDSDK being 32bit only). – Kamil.S Aug 12 '17 at 05:30
  • I'll check that out! I think it is older but it's a good place to start. That also just generally gives me the idea of investigating previous versions of the SDK to see if they have this architecture problem or not. In the end, I think this is something that Canon needs to fix in the latest version of the SDK for macOS. I've sent them a question about it and hopefully they will respond and confirm. – OllieBrown Aug 14 '17 at 16:29

3 Answers3

1

I've concluded that this is just an error on the part of those that deliver the EDSDK for mac. They should be compiling this particular bundle as a universal binary, not a 64bit binary. You can work around the problem by simply removing the offending bundle. It appears to just be a plugin and removing it does not seem to immediately affect the SDK. Assuming you have installed the EDSDK framework in /Library/Frameworks then just do this:

sudo rm -rf /Library/Frameworks/EDSDK.framework/Versions/Current/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle

Enter your password when prompted (this assumes you are an admin account) and it will delete the offending plugin.

I have to believe that there may be consequences for removing this plugin at some point and if anyone knows more about this particular bundle/plugin and can explain what removing it will do I'd appreciate the additional insight.

OllieBrown
  • 143
  • 8
1

In addition to @OllieBrown answer, I found in Xcode building for MacOS I had an additional item to remove to stop the link warnings.

link warning- EDSDK.framework/Versions/Current/DPPLibCom.bundle/Contents/MacOS/DPPLibCom: mach-o, but wrong architecture

removing EDSDK.framework/Versions/Current/DppLibCom.bundle stopped the warning.

gheclipse
  • 971
  • 8
  • 13
0

Since the 3.x version there is a split between intergrated versions of DPP RAW capabilities. The original DPP works in x86 mode only and allows inspection and conversion of CR2 files on cams up until a certain models. See the API doc for the list. For recent camera models which rely on the new 64bit DPP engine (v4+?, dppcoreg) you would need x86_64 bit build so it dynamically links to use the latest features. Quite some (Raw) features are dropped, and gradually make their way back in in beta state.

gdh
  • 498
  • 3
  • 14