So on my current laptop has cross compiled binaries for Qt5.13 with Beaglebone Black as target device. At my workplace, we want to have the ability of working on any desktop or laptop on same target to make different components of our Qt project. Normally as per my knowledge and after seeing some github repos that share precompiled Raspberry Pi binaries, I copied the folder containing qmake and other files in hostprefix directory to another computer but Qt creator on that computer says the qmake is not executable. I also have the toolchain I used on one machine copied to another.
Is this some kind PATH related issue or copying the binaries doesn't work at all? Because cross compiling is a pain in the ass especially with a platform like Beaglebone black.
Try to look at this explanation: https://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html
It's possible in Qt Creator to deploy your binaries to a target platform. You just need to setup everything. Then you will be able to compile, deploy and debug remotely.
Related
Background
I have an Android app which uses native ARM64 executables (essentially GCC toolchain, extracted to app directory (/data/data/%package%/somePath) on the first run) to do some work. Due to Android 10 changes files in /data/data/.. can't have executable permission anymore.
Confirmed workaround
The workaround is to make executables look like shared libraries (libsomething.so) that are extracted by Android to /data/app/%package% dir with android:extractNativeLibs="true" in AndroidManifest.xml and are allowed to have executable permission. Symlinking might be useful to mimic the previous files structure.
The problem
The problem is that all the executables (aka new "shared libs") are packed into android apk with zip compression ratio (as apk is essentially just a zip file) which could be better if it's archived with 7zip for instance and together weight more than 100Mb which is app limitation on Android (for apk files).
The question and the proposal
How can i split the executables into a small part (that goes into /data/app/%package% and a large part (or just existing executable in /data/data/%package%)? The idea is that small executable just "loads and runs" a regular one. The benefit it that regular executable is compressed with 7zip and it makes apk size much smaller due to 7zip used with a better compression ratio.
I've been looking into direction of using of UPX but having no experience with it (note i will have to prepare executable on Mac machine (or Linux with VM or Docker) to run on Android ARM64). Also i've been thinking about creating of 7z sfx but it seems to be tricky (again, it have to be created on x86_64 and run on ARM64). Also I've found some similar QA (which recommends memexec() or fexecve()), but I'm not sure what's the optimal way to go.
Ideally I'd love to have some tiny "universal" ARM64 executable (or be able to compile it from the source code with Android NDK) that just accepts cmd and a regular executable path.
PS. App bundle and dynamic delivery modules as high-level alternatives are undesired for different reasons.
PPS. UPX did not work out of box for Android 10 (seems to be security issue).
Does anyone know, how to relocate the QT5 installation on Linux? Especially, all the set paths of the files in the mkspecs directory?
Any tool or script letting Qt5 create these files again is o.k.
I'd like to deploy the files of QT5's "lib/bin/mkspecs..." via a central repository on other computers to be able to seemingless do the compilation.
And no, I really don't want to use the systems QT5 by some package manager.
Thanks for your help!
I have attempted this a few times. It gets really hairy really fast, and my only recommendation is that you re-install to the new location.
The reason is that the path of the installation is hard-coded into so many files in so many locations that even search-replacing them all is really error prone.
1) Download source and make your custom Qt build - http://doc.qt.io/qt-5/build-sources.html
2) Make own package\installer of your builded Qt libraries.
If you want own Qt build for run particular application. Then make right installer for that application include all necessary files.
So I saw this project http://mxe.cc/ and tried it, it seems like it is very easy to compile stuff for windows with this. I tried to hack it a little bit to compile binaries for linux instead, because, if it compiles for other system so easily how can it be hard to compile for host? 90% of the stuff seems to just build out of the box, but there are some errors and therefore I cannot build. I want to ask, how correctly should I configure mxe to build for the linux host? I know this is not supported but I don't think it should be that hard because we build from source anyway. And there are next to no modifications for downloaded sources too (in a windows build that is).
For people who might ask why I don't want to use shared stuff, I want to basically have two options:
dpkg package for user with dependencies specified (the linux way)
single standalone static executable
Any suggestions? Or maybe there's whole another guide on linux on how to build things from scratch (without a lot of manual work like mxe does)?
I have a layered cmake project with a hierarchy of libraries and applications. Each of these libraries and applications has a CMakeLists.txt and a top level CMakeLists.txt that includes the sub-cmake files.
Right now we are developing and testing entirely on an x86 Linux platform but at some point we will want to start pulling the code into a Yocto build and target arm. We want to maintain being able to build for both x86 and arm.
I've seen some Yocto guides on building for x86 but these appear to build the entire world (the toolchain, linux kernel, all libraries etc) and run the image via qemu. For our desktop use this is quite a bit of overkill when our machines have compilers and we can just run the applications directly, but it would be very helpful to have bitbake build some libraries that we have dependencies on and that need to be installed to a 'virtual root'.
How can I use use bitbake for native x86 projects (in place of or in addition to cmake) and be able to leverage the recipe files for Yocto later on?
I don't have much experience with Yocto, but I'm using another embedded Linux distribution with similar concept: Buildroot. Buildroot creates toolchainfile (output/host/usr/share/buildroot/toolchainfile.cmake) for the currently selected toolchain.
You create two output folders for your project:
build-x86
build-arm
I the first folder you just execute:
cmake ../path-to-your-source
In the second one:
cmake ../path-to-your-source -DCMAKE_TOOLCHAIN_FILE=../path-to-buildroot/output/host/usr/share/buildroot/toolchainfile.cmake
If Yocto provides a toolchainfile, you can use it directly. If not you can create it yourself. See this wiki.
Update:
This section explains, how you can add your software to Buildroot (package). Here the source folder override mechanism is described.
Installed FreeImage through MacPorts. Everything looked to be OK, but when I builded my app and tried to launch on other computer where is no MacPorts and no FreeImage installed it says
dyld: Library not loaded: /opt/local/lib/libfreeimage.3.dylib
Referenced from: /Users/development/Library/Developer/Xcode/DerivedData/freeimage-dxsornyaxqlkyubqwsrlkgszvxhy/Build/Products/Debug/freeimage.app/Contents/MacOS/freeimage
Reason: image not found
Shouldn't it copy library files together with my project? I added them to my project's build phases "Copy files" list. They are being copied to my app's bundle. But when I try to link them, I get same error. I don't know why but app is still looking for library in /opt/local/lib. How can I fix it so that I could use FreeImage at my project and run it at any computer?
When you install through MacPorts the library is installed in /opt/local/lib, not in your project path. Even if you copy the whole project, the *dylib libraries won't be copied because they are usually in /opt/local/lib.
I believe you have two options here: install FreeImage in every computer that you want to run your application, or copy the libfreeimage.3.dylib to the same folder where your binnary is and, if both systems are similar, that should work. If the two computers are different in terms of operating system version, hardware architecture, etc... then probably the .dylib that you have won't be compatible for the other computer.
Another thing you might want to consider is to modify your DYLD_LIBRARY_PATH variable, which specifies the paths in which the OS will look for libraries when linking. See this answer for more information.