<br><br>On Monday, January 10, 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 Sun, 9 Jan 2022 19:48:40 +0100<br>
<<a href="mailto:mnieuw@zap.a2000.nl">mnieuw@zap.a2000.nl</a>> wrote:<br>
<br>
<snip><br>
> > still, it seems<br>
> > <br>
> > cmake_config=echo 'cmake "$$$$@" "$(1)"' > ./configure; chmod +x<br>
> > ./configure;<br>
> > <br>
> > a bit above already does this step, not sure why it failed for you..<br>
> >   <br>
> <br>
> Maybe because it does not do it in the root directory of that source.<br>
> but one deeper?<br>
> I was away, just started a complete build after "make clean" without<br>
> my libaom mod to the makefile. We'ĺl see what happens. I left my<br>
> giflib mod in place.<br>
<br>
I am happy to report that the aarch64 version of CinGG builds properly<br>
here with libaom enabled. The change in the thirdparty Makefile<br>
compared to the git is now only the added creation of a dummy<br>
configure script through giflib.cfg_vars .</blockquote><div><br></div><div>this is still with my fix for libaom patch, right? </div><div><br></div><div>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..) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know why it failed earlier when enabling libaom, possibly<br>
because I did not do a full rebuild. I did now, take 5 hours with<br>
libaom included. I will upgrade my CPU.</blockquote><div><br></div><div>if software can do trick - why upgrade hw?  :-) </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, but I<br>
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.</blockquote><div><br></div><div><br></div><div>supposedly proot can help here:</div><div><br></div><div><a href="https://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg04870.html">https://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg04870.html</a></div><div><br></div><div> ===</div><div>PRoot can also mix automatically the execution of host programs and</div><div>the execution of guest programs emulated by QEMU user-mode.  It's a</div><div>convenient way to speed up build-time by using a cross-compiler</div><div>instead of emulating the guest compiler.  Even when mixing such</div><div>applications, build-systems still believe they are running in a native</div><div>guest environment, as a consequence most cross-compilation issues are</div><div>avoided by design.  For instance, with a typical "./configure" script</div><div>(many lines were removed for readability purpose):</div><div><br></div><div>    <linux-x86>$ proot -Q qemu-arm /path/to/any/arm-rootfs/</div><div><br></div><div>    <linux-arm>$ ./configure </div><div>CC=/host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc</div><div>    checking whether build environment is sane... yes</div><div>    checking build system type... armv7l-unknown-linux-gnueabi</div><div>    checking host system type... armv7l-unknown-linux-gnueabi</div><div>    checking for gcc... /host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc</div><div>    checking whether the C compiler works... yes</div><div>    checking whether we are cross compiling... no</div><div><br></div><div>===</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
MatN <br>
<br>
</blockquote>