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
Related
I have a board with zynq chipset and Armv7 processor and Ubuntu 12.04. I want to remotely build and debug a c++ program on it with QtCreator.
I tried to create a kit for building the program using this link. added the compiler in the toolchains of board and added qt version 4.8.1 to the kit (version of qt on the board is 4.8.1).
The code builds successfully. the problem is the binary is not executable on my board because it seems it is a 64bit binary and my board is not 64bit.
Am I missing something?
how can I check if my config for compiling qt everywhere source was correct and it resulted in the qmake I wanted?
btw my own OS is Ubuntu 16.04 64bit.
The instruction on the Xilinx's page instruct how to build a cross compiler for ARM, however I belive they assumed you're going to follow these steps on 32-bit Linux platform. On the other hand -xplatform qws/linux-arm-gnueabi-g++ option should produce 32bit compiler.
Are you sure your code is build with right compiler build with right option? have you trie to build any minimal example from command line and check what file command is telling you about the binary produced? For me it looks like, do don't really cross-compile your project.
after hours and hours of searching and trying different things I found the reason. First of all as #michal-f said I installed 32-bit Ubuntu. making in terminal was resulting in ARM binary but QtCreator just compiled for intel proccessor.
as stupid as it seems the reason was that I did not know that Qt variables is not related to system variables and though I had added CROSS_COMPILE variable in terminal, I should have added it to my kit environmental variables too.
so the phrase ${CROSS_COMPILE}g++ in MakeFile was simply g++ and the output was a binary compile with system g++.
I know it was something I should have found sooner, but something this stupid should have been somewhere on internet for beginners like me. So hopefully next person encountering this same problem will find this post.
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.
Good day all
I have been searching for a method of cross-compiling for QT-Creator in Linux for sometime now, and I have been having alot of trouble with it.
Background info
please note: I am on a Linux machine, and would like to cross compile Windows Apps
My system:
Ubuntu Gnome 16.10
QT Creator 4.0.2 (based on QT 5.7)
I have came across a few SO links, a few blogs with broken instructions, etc and one seeming helpful but dependencies could not be found.
I have also attempted another compiler MXE and cloned and attempted to build the MXE compiler from the GIT repo, which failed (no solution for the build error - VTK build error)
I decided to download precompiled MinGW compilers (i686 and x86_x64 versions) from sourceforge
Issue:
In QT Creator, adding the compiler is done without an issue, adding the "Kit" and selecting the newly added compiler, an red exclamation gives an error
The Compiler (x86_windows_msys_pe_64bit) cannot produce code for QT version 5.7.0 GCC 64Bit (x86_linux_generic_elf_64bit)
This occurs for both 32 + 64 bit compilers.
I think that you should have a QT version that matches your compiler ABI. The error tells you that the MinGW compiler doesn't match the Linux version of QT you have used. Therefore, get a windows version of QT and use it instead (just as you've added WinGW).
You can download Qt Binaries from here.
I got my self an ARM based development board (NVIDIA Jetson K1).
The thing is already equipped with Ubuntu system. I was able to use gcc 4.8 directly on the device, but it doesn't contain g++. Installing g++ with apt-get as usual wouldn't work because nobody ever bothered to maintain a complete ppa supporting ARM architecture.
Now I tried to compile the latest GCC manually. Everything went smooth when I compile and installed the requirements (MPC, MPFR, GMP). But I failed building GCC itself, and found out that the mad error in config.log telling me that a working C++ compiler can not be found.
I believe there must be a way to get a working g++ compiler working on the device itself rather than having to cross compile. Does anyone have a clue on how this can be done?
The message is right. GCC 4.8 is written in C++ so it needs to be compiled with a C++ (cross) compiler.
I'm running CentOS 6.4 and need a later version of the C++ compiler to build my development tools (Qt Creator in this case).
I'm unclear on the implications of using devtools and I'm hoping someone can explain.
If I compile programs using devtools, does that means the executable will run on other Centos 6.4 installations without change?
Or..do I know have to ship libraries or other files with my compiled programs?
If so...do I have to modify my C++ code to reference the later libraries? or is this something done by the person installing my compiled program
I hope this somewhat late answer can still help you. What I found is that compiling my project with devtoolset (1.1 in my case, but that should not matter too much) on RHEL 6.4 produces binaries which can almost run on a standard RedHat EL 6.4 (should be similar for Centos 6.4).
The only trouble I ran into was compiling my project with -std=c++11, which produced some problems due to incompatible symbols. The reason is that the GCC folks considered these parts of the standard library to be experimental in GCC 4.4, so they broke ABI compatibility in some places.
Turns out, there's an easy fix: Link your programs with the additional command-line-argument -static-libstdc++. That way, the binary becomes a bit larger but is runs on an unmodified RHEL 6.4 without installing additional libraries/updates for the devtoolset.
To answer your questions explicitly:
Yes, almost.
No.
Don't change the code, just add -static-libstdc++ when linking.