On Saturday, January 8, 2022, Phyllis Smith <[email protected]> wrote:
MatN -- EXCELLENT !! your patience is amazing.
I want to try this on my Android tablet but I have not figured out how to get the CinGG files there (no USB connection and when I started a download from cinelerra-gg.org/download/src it was so slow, I stopped it; I will try something else).
try trasnsferring compressed tarball via browser/bluetooth and then grant Termux acces to storage [0] and unpack from there like tar -xf ~/storage/downloads/Broswer/tar_file.tar.gz (bluetooth folder is different)
Do I need to worry about "can you check if you NOT have 'set - e' somewhere before you run make?" Was there some trick I will need to do because yesterday, you noted that it did NOT work?
I think Mat disabled both libdav1d and libaom via configure switches... [0] https://wiki.termux.com/wiki/Internal_and_external_storage
On Fri, Jan 7, 2022 at 2:27 PM <[email protected]> wrote:
Joy!
Thanks to Andrew, CinGG builds on Debian 11 aarch64 (Qemu emulation) now. It took 4.5 hours. I will examine the log tomorrow, but it starts fine.
MatN
On Wed, 5 Jan 2022 15:04:13 -0700 Phyllis Smith via Cin <[email protected]> wrote:
Checked into GIT, thirdparty/Makefile which includes the modifications from Andrew of autoconf/autoreconf needed for aarches64 and the lidv-1.0.0.patch0 (also needed because libdv would not compile without it on Fedora 32 or Debian 11.0 32-bit). Attached is its log file when it would not compile. Before adding the patch, I had installed what I could find on a Fedora system for "libsdl1(-dev)" but it did not fix the error -- I did a "yum install libsdl*" and it installed stuff but I only saw version 2 and not 1 and did not see any libsdl at all. Also checked another Fedora system to see what it would have installed and I just get: [root@keystone Downloads]# yum install libsdl1* Last metadata expiration check: 1:05:20 ago on Wed 05 Jan 2022 01:55:05 PM MST. No match for argument: libsdl1* Error: Unable to find a match: libsdl1*
Part of the patch contained these lines which I thought were HILARIOUS ! +# Configure paths for SDL +# Sam Lantinga 9/21/99 +# *stolen from Manish Singh* +# s*tolen back from Frank Belew* +# s*tolen from Manish Singh* +# *Shamelessly stolen from Owen Taylor*
On Tue, Jan 4, 2022 at 5:54 AM Andrew Randrianasulu <[email protected]> wrote:
just put in thirdparty/src as libdv-1.0.0.patch0 and see if it helps ?
I build with clang, also (default for x86 linux usually gcc)
On Tuesday, January 4, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, January 4, 2022, Phyllis Smith <[email protected]> wrote:
Andrew, attached is the thirdparty Makefile that I would like to check into GIT tomorrow. I hope it includes all of the patches you provided in respect to autoconf. It builds and runs correctly on Fedora 32 and Debian 32-bit 11.0 Bullseye. The only thing that I know is still missing is the line: libdv.cfg_vars?= autoreconf -ifv -I m4 && automake -caf; which I have commented out. It fails on both Fedora and Debian (I will have to attach another config.log file but forgot to move it over yet). I will look at it again tomorrow but may have to wait until MatN looks at it to figure out what is wrong.
you tried to install libsdl1(-dev) on build host?
I have it onstalled as dependency of some other package...
sorry, not yet extracted patch supposed to fix 'autoreconf in libdv in adsense of libsdl' from previous mail...
but thanks anyway....
Even STRANGER than you think! When I compare "exit 2" (the non-working >> config.log) to "exit 0" (the working config.log), it shows the >> bad one using Autoconf 2.6*9 *but the one that works uses >> Autoconf 2.6*0.* This does not make sense. And so 2.6*9* may >> be causing the problem identified on line 52 but I do not know >> why. There must be a parameter on the ling >> Line 52: configure:2661: WARNING: 'missing' script is too old >> or missing >> >> There must be a parameter on the line: libdv.cfg_vars?= >> autoreconf -ifv -I m4 && automake -caf; >> that makes it use a different autoconf? >> > > yeah, it was part of change required for for auto-updating > config. guess (for aarch64) > >