<br><br>On Tuesday, January 11, 2022,  <<a href="mailto:mnieuw@zap.a2000.nl">mnieuw@zap.a2000.nl</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 10 Jan 2022 22:43:52 +0300<br>
Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br>
<br>
<snip><br>
> > I am happy to report that the aarch64 version of CinGG builds<br>
> > properly here with libaom enabled. The change in the thirdparty<br>
> > Makefile compared to the git is now only the added creation of a<br>
> > dummy configure script through giflib.cfg_vars .  <br>
> <br>
> <br>
> this is still with my fix for libaom patch, right?<br>
<br>
Yep, I can make a diff if you want.<br>
<br>
> Also,.... does resulting cin binary works? (as in, show gui, allow you<br>
> loading vids and images, edit them a bit and encode result? obviously<br>
> on emulated aarch64 machine you want some small video, like<br>
> 320x240... I think..)<br>
<br>
Will test today, audio file loads and plays fine (but still no sound<br>
from the VM).<br>
 <br>
> if software can do trick - why upgrade hw?  :-)<br>
<br>
The faster CPU (from 8 threads Zen to 16 threads Zen3) will speed up<br>
rendering too.</blockquote><div><br></div><div><br></div><div>yeah... well, if hw  upgrade is possibility fir you.. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > It might be worth investigating if cross-compile is an option, e.g.<br>
> > build an Linux aarch64 version on Linux 86_64. The tools exists,<br>
> > but I don't know if the configure scripts / cmake can handle that.<br>
> > Cross-compiling would limit the slow arm emulation to the testing of<br>
> > the build products.  <br>
> <br>
> <br>
> <br>
> supposedly proot can help here:<br>
> <br>
> <a href="https://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg04870.html" target="_blank">https://lists.nongnu.org/<wbr>archive/html/qemu-devel/2012-<wbr>03/msg04870.html</a><br>
> <br>
>  ===<br>
> PRoot can also mix automatically the execution of host programs and<br>
> the execution of guest programs emulated by QEMU user-mode. It's a<br>
> convenient way to speed up build-time by using a cross-compiler<br>
> instead of emulating the guest compiler. Even when mixing such<br>
> applications, build-systems still believe they are running in a native<br>
> guest environment, as a consequence most cross-compilation issues are<br>
> avoided by design. For instance, with a typical "./configure" script<br>
> (many lines were removed for readability purpose):<br>
> <br>
>     <linux-x86>$ proot -Q qemu-arm /path/to/any/arm-rootfs/<br>
> <br>
>     <linux-arm>$ ./configure<br>
> CC=/host-rootfs/opt/devkit/<wbr>armv7/bin/armv7-linux-gcc<br>
>     checking whether build environment is sane... yes<br>
>     checking build system type... armv7l-unknown-linux-gnueabi<br>
>     checking host system type... armv7l-unknown-linux-gnueabi<br>
>     checking for gcc...<br>
> /host-rootfs/opt/devkit/armv7/<wbr>bin/armv7-linux-gcc checking whether<br>
> the C compiler works... yes checking whether we are cross<br>
> compiling... no<br>
<br>
I will look at your suggestion of using PRroot. However, that msg is 10<br>
years old, and refers to qemu in user mode. I am just about to move to<br>
system mode, because file sharing will not work in user mode, and maybe<br>
that will fix the audio issue too.</blockquote><div><br></div><div>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. </div><div><br></div><div>also, proot still active project (unlike scratchbox2 from same message). </div><div><br></div><div>Just I thought you might try it as alternative. Bugs might prevent you/us from running it .. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the msg says:<br>
==============<br>
As you probably know, QEMU user-mode is mainly used with binfmt_misc,<br>
chroot, and sometimes "mount --bind".  <br>
==============<br>
This is not my understanding as it is used now. You just run a full<br>
distro in it, be it Linux or some other OS.</blockquote><div><br></div><div>well, qemu's own docs not very useful at this moment</div><div><br></div><div><a href="https://www.qemu.org/docs/master/user/main.html">https://www.qemu.org/docs/master/user/main.html</a></div><div><br></div><div>but Debian's documentation  looks better</div><div><a href="https://wiki.debian.org/QemuUserEmulation">https://wiki.debian.org/QemuUserEmulation</a></div><div>===</div><div>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).</div><div>====</div><div><br></div><div><br></div><div>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! </div><div><br></div><div>But I haven't tested this yet, due to difference in how clang (my host compiler in Termux) handles cross-compilation.. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
MatN<br>
</blockquote>