[Cin] libaom 3.2.0 patch1 fixed for arm/linux?

[Andrew Randrianasulu]

On Monday, January 10, 2022, <mnieuw at zap.a2000.nl> wrote:

> On Sun, 9 Jan 2022 19:48:40 +0100
> <mnieuw at zap.a2000.nl> wrote:
>
> <snip>
> > > still, it seems
> > >
> > > cmake_config=echo 'cmake "$$$$@" "$(1)"' > ./configure; chmod +x
> > > ./configure;
> > >
> > > a bit above already does this step, not sure why it failed for you..
> > >
> >
> > Maybe because it does not do it in the root directory of that source.
> > but one deeper?
> > I was away, just started a complete build after "make clean" without
> > my libaom mod to the makefile. We'ĺl see what happens. I left my
> > giflib mod in place.
>
> 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?

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..)


> I don't know why it failed earlier when enabling libaom, possibly
> because I did not do a full rebuild. I did now, take 5 hours with
> libaom included. I will upgrade my CPU.


if software can do trick - why upgrade hw?  :-)

>
> 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

===


> MatN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220110/ebd5c132/attachment.htm>