On Tuesday, January 11, 2022, <[email protected]> wrote:
On Mon, 10 Jan 2022 22:43:52 +0300 Andrew Randrianasulu <[email protected]> wrote:
<snip>
I am happy to report that the aarch64 version of CinGG builds properly here with libaom enabled. The change in the thirdparty Makefile compared to the git is now only the added creation of a dummy configure script through giflib.cfg_vars .
this is still with my fix for libaom patch, right?
Yep, I can make a diff if you want.
Also,.... does resulting cin binary works? (as in, show gui, allow you loading vids and images, edit them a bit and encode result? obviously on emulated aarch64 machine you want some small video, like 320x240... I think..)
Will test today, audio file loads and plays fine (but still no sound from the VM).
if software can do trick - why upgrade hw? :-)
The faster CPU (from 8 threads Zen to 16 threads Zen3) will speed up rendering too.
yeah... well, if hw upgrade is possibility fir you..
It might be worth investigating if cross-compile is an option, e.g. build an Linux aarch64 version on Linux 86_64. The tools exists, but I don't know if the configure scripts / cmake can handle that. Cross-compiling would limit the slow arm emulation to the testing of the build products.
supposedly proot can help here:
https://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg04870.html
=== PRoot can also mix automatically the execution of host programs and the execution of guest programs emulated by QEMU user-mode. It's a convenient way to speed up build-time by using a cross-compiler instead of emulating the guest compiler. Even when mixing such applications, build-systems still believe they are running in a native guest environment, as a consequence most cross-compilation issues are avoided by design. For instance, with a typical "./configure" script (many lines were removed for readability purpose):
<linux-x86>$ proot -Q qemu-arm /path/to/any/arm-rootfs/
<linux-arm>$ ./configure CC=/host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc checking whether build environment is sane... yes checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking for gcc... /host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc checking whether the C compiler works... yes checking whether we are cross compiling... no
I will look at your suggestion of using PRroot. However, that msg is 10 years old, and refers to qemu in user mode. I am just about to move to system mode, because file sharing will not work in user mode, and maybe that will fix the audio issue too.
I think you already using system mode (full system emulation - so you can run NetBsd or MacOS or windows - they see emulated/virtual machine to run on..) User-mode qemu run Linux binaries on top of same kernel BUT they can belong to another architecture! So overhead can be less.. (no mmu emulation). You can edit files inside proot 'vm' from host - no need for samba/nfs. also, proot still active project (unlike scratchbox2 from same message). Just I thought you might try it as alternative. Bugs might prevent you/us from running it ..
Also, the msg says: ============== As you probably know, QEMU user-mode is mainly used with binfmt_misc, chroot, and sometimes "mount --bind". ============== This is not my understanding as it is used now. You just run a full distro in it, be it Linux or some other OS.
well, qemu's own docs not very useful at this moment https://www.qemu.org/docs/master/user/main.html but Debian's documentation looks better https://wiki.debian.org/QemuUserEmulation === This page describes how to setup and use QEMU user emulation in a "transparent" fashion, allowing execution of non-native target executables just like native ones (i.e. ./program). ==== Main feature from proot (aside from running as regular user - useful for me on non-rooted Android!) seems to be this accelerated cross-compiling - cross-compiler still runs from x86_64 host (not emulated at all - > fast!), yet interacts with headers, libraries and source files inside our (arm/aarch64) chroot! But I haven't tested this yet, due to difference in how clang (my host compiler in Termux) handles cross-compilation..
MatN