The current issue I am experiencing is setting up CMAKE for cross-compiling for the AARCH64 environment. The C++ project does reference some other third party libraries such as boost for its compiling.
I have read the documentation, but it is not really clear on the step-by-step procedure on what needs to be done in order to cross-compile using CMAKE for aarch64 on a x86_64 environment.
I have read that I need the rootfs of the aarch64 system, others it states I dont need it and only need the c++ compiler and cross headers/libraries.
At the current moment I am trying to compile the project on a Mustang board. But it runs in to issues with referencing the installed libraries for the x86_64 system.
If there is a person or site that could detail setup by step what would need to be done to this environment in order to get the entire project to cross-compile for aarch64 on a x86_64 system. I would greatly appreciate it.
Related
I use conan as a dependency manager for a large C++ project. The project was built for Linux and I am porting it to Windows.
Due to this I am compiling with mingwin since that development environment is closer to mine.
However, conan knows it's running on windows and so it downloads windows binaries.
I am finding that although compilation works, linking fails because mingwin binaries and MSVC binaries are incompatible.
I am not sure if I need to try to instruct meson (my build system) to use cl as the compiler, or trick conan to download Linux libraries instead of windows.
Currently, I'm developing a C/C++ Application with the following characteristics:
Multiple target platforms - ARM (Raspbian) and manufacturer-modified x86 distribution
CMake is used to compile C/C++ application
Cross-compilation for ARM and the customized x86 distribution => with CMake (and toolchains to cover cross compilation)
Multiple dependencies (other github repositories) which are separately cross-compiled (according to github READMEs). These are referenced in the CMake of the project. The CMake decides if it uses the ARM or x86 libs.
For deploying I copy the cross-compiled dependency libs to /usr/lib on the target. Afterwards, the cross-compiled application can be launched on the target.
As cross-compilation is very annoying because it's full of pitfalls and I'll need many more dependencies in future, I decided to move to another build system to make things easier:
My goal is to get a rpm/deb file which can be easily installed on the target systems
After a few hours of research, I found out that via Yocto cross-compilation can be managed easier. In addition, it's possible to build deb/rpm/... files which can be installed on the targets.
Anyhow, as far as I understood, this deb/rpm/... file can be only installed on the yocto distribution/image which has been used for compiling => In other words, I would have to flash a completely new distribution on our targets (raspberry & x86). Unfortunately, this is no option for me (because of the custom x86 target).
Question 1: Is it correct that I have to replace the distributions on the targets in order to install the created packages?
Question 2: Is there a way how to create cross-compiled deb files which can be installed on existing distributions? If yes, what do I have to do to achieve this?
I assume that my current build strategy isn't the best. If you have any idea how to make it better, feel free to let me know.
Thanks,
Christoph
I use install Arch Linux with duel booted Linux Mint 18.1 .In my college we have lubuntu 16.04 and Ubuntu 14.04 installed. I have also enabled testing repos in arch Linux so I get newer packages, thus due to this when I compile any C++ program on Arch it won't run on Linux Mint due to version of shared libraries don't match in mint.
like libMango.so.64 is in arch and libMango.so.60 is on mint. How can I overcome with this ?
so I am asking for how can I compile any C/C++ with newer compiler and shared libraries to to run fine with old shared libraries ? Just like I compile 32 bit programs on 64 bit machine with -m32 flag , is there flag for old shared libraries too ?
I am using gcc 8.1.
how can I compile any C/C++ with newer compiler and shared libraries to to run fine with old shared libraries ?
You cannot do that reliably if the API (or even the ABI, including size and alignment of internal structures, offsets of fields, vtables organization) of those libraries have changed incompatibly.
In general, you'll better recompile your source code on the other computer (and your college might forbid that, if that source is unrelated to your education). BTW, if your source code sits in some git repository (e.g. github if it is open source) transferring on multiple computers is very easy.
Some very few libraries make genuine (and documented) efforts on being compatible with other versions of them in binary form (e.g. at the ABI level), but this is not usual. The Unix and free software tradition is to care about source level compatibility. And the POSIX standard cares only about source compatibility.
You might consider using some chroot-ed environment (see chroot(2) and path_resolution(7) & credentials(7)) to have the essential parts of your older distribution on your newer one. Details are distribution specific (on Debian & Ubuntu, see also schroot and debootstrap). You could also consider running a full distribution in some VM, or using containers à la Docker.
And you might try to link (locally) your executable statically, so compile and link with g++ -static
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 currently programming an extension to a program, which only supports
i386 (and I am running amd64 Ubuntu 11.10). Whenever I compile my extension source
I need to use the -m32 flag to force 32 bit architecture (otherwise the program will not be able to load my extension). Sooner or later it is inevitable to avoid boost
thanks to its huge and stable library, which leads to my problem.
I want to use the boost filesystem, which uses OS specific function calls, which in turn leads to the requirement of a library file instead of only a header implementation. The problem is; I can't/don't know how to setup the boost filesystem (i386 version) on my amd64 machine. If I download a prebuilt (.deb) package for i386 and install it using -force-architecture it still fails complaining about dependencies.
So basically; how do I setup boost with 32bit (i386) architecture on my (amd64) system?
It seems as if I did it right all along but I was too dumb to realize how to properly link libraries with the GCC linker, coming from a Windows environment. You can easily compile boost libraries by using the -m32 flag and by setting up bjam properly. See the first answer in this question for details: How do I force a 32 bit build of boost with gcc?