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)
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.
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.
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.
Related
I have MacBook Air with m1 chip and tried to install SFML according to the instructions on the official website however I can not compile the project for example
enter image description here
EDIT: I moved the Xcode app act via rosetta 2 and now it works I would love to know if there is a solution that will activate it natively
The error you are receiving is telling you that the version being linked is for MacOS on x32_64, while trying to compile for arm64. This is incompatible, given they're two different platforms.
Are you compiling SFML from source? It doesn't look like SFML has precompiled binaries for MacOS-arm64, but the source code does have arm compatibility. Compiling from source would be operating system agnostic as long as everything is there (and supports arm64.) SFML has an article on how to compile from source with CMake: https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php
While I can't guarantee this will fix your issue, it's definitely worth a try if you haven't yet.
The reason using Rosetta made this work is because Rosetta emulates some parts of x32_64. Running these apps in Rosetta would essentially be the same as compiling your project on an Intel based Mac.
I found the solution if it can help some, just make your pc believe that you have an intel chip, by adding /usr/bin/arch -x86_64 before your order.
example:
/usr/bin/arch -x86_64 clang main.c -lcsfml-graphics -lcsfml-system
I have a problem when I tried to install SFML on Codeblocks. Well, first I install codeblocks: codeblocks-20.03mingw-setup.exe . That's compile correctly after that I download SFML 2.5.1: GCC 5.1.0 TDM (SJLJ) - Code::Blocks - 32-bit.
Following, I extract the SFML file.The problem comes I COPY THE CONTENT OF "BIN" INSIDE OF MY CODEBLOCKS PROJECT. A video helps me to do all of before, I WROTE ALL THE LIBRARIES: GRAPHICS, WINDOW, NETWORK, AUDIO, SYSTEM BUT NOTHING. I show you the error:
cannot find -lsfml-audio-d-2
And continue with network, window,system, graphics
At the ends:
error: ld returned 1 exit status
what's wrong? help me please. I have to make a video game using CODEBLOCKS as soon as I fixed this problem. I'll so thankful for your answers.
On the SFML download website (https://www.sfml-dev.org/download/sfml/2.5.1/), it says:
The compiler versions have to match 100%!
The CodeBlocks 20.03 MinGW installation includes version 8.1.0 of the GCC compiler (as is stated on the download page: http://www.codeblocks.org/downloads/26).
Your downloaded version of SFML thus is only intended to work with version 5.1.0 of GCC, but you have version 8.1.0. This can result in a number of errors.
There are a few possibilities to fix your issue:
You could theoretically compile SFML yourself with your specific compiler, but this option may be quite complicated.
You could use a compiler with the matching version. On the SFML download website, there are some links to the needed compilers. After having installed a compiler, you will have to configure CodeBlocks to detect the new compiler on your system (reference: Adding compiler to code::blocks). Now, in order to add SFML to your project, I would suggest to use this official guide:
https://www.sfml-dev.org/tutorials/2.5/start-cb.php
You could use an environment like MSYS2 (which I use personally) to have a package manager to manage your compiler and libraries installations. This way, your compiler installation and your libraries should work with each other. But in order to use this compiler in CodeBlocks, CodeBlocks would have to be configured.
I would suggest that you refer to option 2 because it probably is the quickest solution.
Feel free to ask if you have any more questions. I know from personal experience that setting up SFML (or any other C++ library) to work with your IDE may be quite tricky.
I am trying to compile a 32-bit application on 64-bit Debian Stretch. I have compiled several other applications successfully this way, but one app that uses the pcap library is giving me problems. There does not seem to be a 32-bit version of this library anywhere for my platform.
Problem description
When I try to link my application, like this:
g++ (...objectfiles-and-options...) -m32 -o myapp -lpthread -lpcap
I get the error
/usr/bin/ld: cannot find -lpcap
I checked, and there is indeed no libpcap.so (or variant thereof) in /usr/lib32. However, all other libraries I am using is present there (like libpthread). I tried to create soft-links to the 64-bit pcap-libraries in there, just in case they should be multi-platform compatible, but that only resulted in "skipping incompatible /usr/lib32/libpcap.so when searching for -lpcap".
I've installed libpcap-dev, libc6-dev-i386, gcc-multilib and g++-multilib (obviously, since cross-compilation works fine for all applications that does not use libpcap). I would suspect there should be a libpcap-dev-i386 I could install, but there does not seem to be one.
Perhaps I should mention that the application compiles and links successfully as 64 bit.
Does anyone know what I am missing here?
You can compile libpcap yourself. It's probably the better solution than depending on packages.
Use configure for 32bit architecture and than give your compiler LDFLAGS pointing to your lib or install it in /usr/lib32/
I downloaded the sfml GCC - 32-bit version for linux; though my operating system is ubuntu. I am able to compile a test program, but when I try to link the libraries I get an error:
dylan#Aspire-one:~/Documents/SFML-2.3.1/projects$ g++ test.o -o sfml-app -L/home/dylan/Documents/SFML-2.3.1/lib -lsfml-graphics -lsfml-window -lsfml-system
/home/dylan/Documents/SFML-2.3.1/lib/libsfml-graphics.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)#GLIBCXX_3.4.20'
collect2: error: ld returned 1 exit status
If you have any clues please comment below, but I would appreciate a full answer.
Expanding on my earlier comment: It looks like you have SFML binaries that are linked to a version of glibc that isn't on your system. You need to either install that version of glibc (3.4.20, 32 bit) or get/build SFML binaries that link to a version of glibc that you do have.
The Linux world is different from the Windows and the Mac worlds. And the right way to do things has changed over the years. And my personal willingness to experiment has changed as well.
You generally want to get binaries from the distribution you use. Ubuntu in your case, Fedora in mine. This allows the package manager (e.g., yum or apt-get) to do its job: determine if you have the needed prerequisites when installing new software, uninstall software as desired, install updates with minimal fuss, etc. If you can't get the binaries you want, at least try to find a repository that you can tell your package manager to trust, so that you can get regular updates.
If you aren't able to find an acceptable package that way, your only option is to build from source. Download the latest source code archive from http://www.sfml-dev.org/download.php (get a release with a version number, instead of "whatever's currently in GitHub"). It looks like SFML currently uses CMake, so you'll want to follow the directions on http://www.sfml-dev.org/tutorials/2.3/compile-with-cmake.php to build.
Personally, I wouldn't run the final make install step. That will copy the binaries to /usr/local or some similar place, but won't notify your package manager about the change. And there won't be a way to uninstall aside from manually deleting the files. Instead, just add the folder you build in to your PATH (and the include folder to your INCLUDE_PATH). You'll be able to develop your application with that setup, and nothing will prevent you from installing the package when somebody finally creates it for your distribution.
I am trying to build and use a piece of C++ code that uses OpenCV. I am working on Linux, working in Code::Blocks (and the code was originally also developed on a Linux platform using C::B).
I followed this to install OpenCV (Ubuntu 12.04 & OpenCV 2.4.3). The project compiles fine, but when I try to execute it, it crashes on launch, with the following message about how it can not find the library:
(file_address): error while loading shared libraries: libopencv_core.so.2.3:
cannot open shared object file: No such file or directory
Process returned 127 (0x7F) execution time : 0.017 s Press ENTER to continue.
I set all the parameters for the linker according to several Code::Blocks install tutorials.
I also checked in /usr/local/lib/ for my libraries (it is the folder I gave to Code::Blocks' compiler); and while I do have a libopencv_core.so, a libopencv_core.so.2.4 and a libopencv_core.2.4.3, I do not have a libopencv_core.so.2.3.
So I'm wondering what the issue is. Is it about backwards compatibility, i.e. do I have to install the exact same version of OpenCV used to develop the original code? (This would be a bit concerning, since I am trying to make a widely-usable library).
Could I force it to use libopencv_core.so.2.4 instead?
EDIT: I managed to make it work by removing everything and reinstalling with a simple apt-get. Sometimes it's the simplest method that works the best! From now on I'll try to apt-get before following installation tutorials. ;)
Have a nice day!