February release with just library updates
The latest release is available with minor Manual updates and updated libraries: libvpx from 1.8.2 to 1.11.0 (only minor testing done so report any issues) libogg from 1.3.4 to 1.3.5 tiff from 4.1.0 to 4.3.0 (except on Debian 11.0 Bullseye 32-bit where it did not build so reverted -- have to analyze yet) fftw from 3.3.8 to 3.3.10 March area of concentration will be aarch64 and termux testing/documentation (help by building and testing if you can!)
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further. MatN
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use. Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there. Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage <https://cinelerra-gg.org/download/images/CinGG-20220131-x86-64-older_distros-multibit.AppImage> ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet. On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way. On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it. If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes" So it looks like a bug in tiff. More to test. MatN On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros- multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
try this plain diff? On Wednesday, March 2, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
Andrew and MatN; The attached patch from Andrew fixes the problem on Debian 32-bit Bullseye (11.0) so I suspect it will also fix it for aarch. Also tested on Fedora 32 which is my usual laptop for my work and it worked just fine. I will check it into GIT sometime today. Thanks to both of you for analyzing this problem. On Wed, Mar 2, 2022 at 3:26 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
try this plain diff?
On Wednesday, March 2, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Yes it works on aarch64 too (Debian 11). MatN On Wed, 2022-03-02 at 13:53 -0700, Phyllis Smith via Cin wrote:
Andrew and MatN; The attached patch from Andrew fixes the problem on Debian 32-bit Bullseye (11.0) so I suspect it will also fix it for aarch. Also tested on Fedora 32 which is my usual laptop for my work and it worked just fine. I will check it into GIT sometime today.
Thanks to both of you for analyzing this problem.
On Wed, Mar 2, 2022 at 3:26 AM Andrew Randrianasulu via Cin <[email protected]> wrote:
try this plain diff?
On Wednesday, March 2, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64- older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh . The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux? MatN
On Friday, March 25, 2022, M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
I hope everything termux-specific lives in blds/bld_termux.sh only small thing I noticed in script - arm8 also can run in 32-bit mode, like my tablet - so may be condition for arm7l can be && with arm8l too? I need to remove few unused default preinstalled (huge!) apps from this tablet, hopefully linux tools will do that too (only tried extracting dirs back in September)
MatN
On Sat, 26 Mar 2022 01:50:04 +0300 Andrew Randrianasulu <[email protected]> wrote:
On Friday, March 25, 2022, M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
I hope everything termux-specific lives in blds/bld_termux.sh
only small thing I noticed in script - arm8 also can run in 32-bit mode, like my tablet - so may be condition for arm7l can be && with arm8l too?
I need to remove few unused default preinstalled (huge!) apps from this tablet, hopefully linux tools will do that too (only tried extracting dirs back in September)
I forgot to mention that for building extra packages are required. patchelf, libboost-filesystem-dev, libboost-regex-dev . These are the names on Debian, will find out for the other platforms and update bld_prepare.sh . For building, arm7l needs more things disabled than arm8, so I'd prefer to enable as much as possible. Have not tried yet the arm7 build on the arm8 qemu libvirt, will do. CinGG build and loads on arm7 (armhf), but have done little testing. On the only arm hardware I have (not counting simple smartphone), it loads but has problems, but it is a very small machine. And, the new tool makeappimage does not build there with a weird compile error, still have to look at it. MatN
Hi Andrew, In configure.ac is a test for Android with "uname -o" . The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)? MatN
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)?
yeah, 'uname -o' also does not work on netbsd. on termux I have $ uname -o Android $ uname Linux $ anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there.. thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
MatN
On Mon, 2022-04-04 at 16:18 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply
"uname" returns the OS name (Linux or Darwin). Does this work for
Termux too (returning Android or at least something where you can act
on)?
yeah, 'uname -o' also does not work on netbsd.
on termux I have
$ uname -o Android $ uname Linux $
Ok, then a test first with "uname" seems best, if it does not return "Darwin" then "uname -o" . I can test freeBSD too.
anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there..
thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
I think many of the thirdparty stuff only works properly with bash too. So we should detect which system we're running on and make sure bash is the shell. Or, if there is no /bin/bash, stop the process. If /bin/bash is missing, then probably more too. MatN
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 16:18 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)?
yeah, 'uname -o' also does not work on netbsd.
on termux I have
$ uname -o Android $ uname Linux $
Ok, then a test first with "uname" seems best, if it does not return "Darwin" then "uname -o" . I can test freeBSD too.
anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there..
thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
I think many of the thirdparty stuff only works properly with bash too. So we should detect which system we're running on and make sure bash is the shell. Or, if there is no /bin/bash, stop the process. If /bin/bash is missing, then probably more too.
thing is, bash can be instalked by default in some other place. some say to use '/usr/bin/env bash' instead.. https://stackoverflow.com/questions/16365130/what-is-the-difference-between-...
MatN
On Mon, 2022-04-04 at 17:30 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 16:18 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)?
yeah, 'uname -o' also does not work on netbsd.
on termux I have
$ uname -o Android $ uname Linux $
Ok, then a test first with "uname" seems best, if it does not return "Darwin" then "uname -o" . I can test freeBSD too.
anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there..
thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
I think many of the thirdparty stuff only works properly with bash too. So we should detect which system we're running on and make sure bash is the shell. Or, if there is no /bin/bash, stop the process. If /bin/bash is missing, then probably more too.
thing is, bash can be instalked by default in some other place. some say to use '/usr/bin/env bash' instead..
https://stackoverflow.com/questions/16365130/what-is-the-difference-between-...
What about putting this in the beginning of bld.sh and bld_appimage.sh, just after the #! /bin/bash if [ $SHELL != /bin/bash" ] ; then echo "Having shell /bin/bash is mandatory" echo "Stopping build" exit fi MatN
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 17:30 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 16:18 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)?
yeah, 'uname -o' also does not work on netbsd.
on termux I have
$ uname -o Android $ uname Linux $
Ok, then a test first with "uname" seems best, if it does not return "Darwin" then "uname -o" . I can test freeBSD too.
anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there..
thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
I think many of the thirdparty stuff only works properly with bash too. So we should detect which system we're running on and make sure bash is the shell. Or, if there is no /bin/bash, stop the process. If /bin/bash is missing, then probably more too.
thing is, bash can be instalked by default in some other place. some say to use '/usr/bin/env bash' instead..
https://stackoverflow.com/questions/16365130/what-is- the-difference-between-usr-bin-env-bash-and-usr-bin-bash
What about putting this in the beginning of bld.sh and bld_appimage.sh, just after the #! /bin/bash
if [ $SHELL != /bin/bash" ] ; then echo "Having shell /bin/bash is mandatory" echo "Stopping build" exit fi
apparently user shell and software building shell can be different things... https://openindiana.org/pipermail/openindiana-discuss/2021-January/023434.ht... i tried 'which bash' and it outputs correct path to bash on termux. does it work for Apple/Freebsd?
MatN
On Mon, 2022-04-04 at 18:24 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 17:30 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, mat <[email protected]> wrote:
On Mon, 2022-04-04 at 16:18 +0300, Andrew Randrianasulu wrote:
On Monday, April 4, 2022, <[email protected]> wrote:
Hi Andrew,
In configure.ac is a test for Android with "uname -o" .
The -o option is not available in macOS. On Linux and macOS, simply "uname" returns the OS name (Linux or Darwin). Does this work for Termux too (returning Android or at least something where you can act on)?
yeah, 'uname -o' also does not work on netbsd.
on termux I have
$ uname -o Android $ uname Linux $
Ok, then a test first with "uname" seems best, if it does not return "Darwin" then "uname -o" . I can test freeBSD too.
anyway, on some linux systems (void linux) default shell also dislikes += constructs, and I hand-edit configure as created by ./autogen.sh there..
thing is, bash can be for example in/usr/pkg/bin, (netbsd) or in some other location. not sure how to convince autotools to search for bash and put this (non-default) interpreter at very first line in our configure...
I think many of the thirdparty stuff only works properly with bash too. So we should detect which system we're running on and make sure bash is the shell. Or, if there is no /bin/bash, stop the process. If /bin/bash is missing, then probably more too.
thing is, bash can be instalked by default in some other place. some say to use '/usr/bin/env bash' instead..
https://stackoverflow.com/questions/16365130/what-is-the-difference-between-...
What about putting this in the beginning of bld.sh and bld_appimage.sh, just after the #! /bin/bash
if [ $SHELL != /bin/bash" ] ; then echo "Having shell /bin/bash is mandatory" echo "Stopping build" exit fi
apparently user shell and software building shell can be different things...
https://openindiana.org/pipermail/openindiana-discuss/2021-January/023434.ht...
i tried 'which bash' and it outputs correct path to bash on termux. does it work for Apple/Freebsd?
Will check on macOS and freeBSD.
Andrew, does the attached configure.ac work for you? It produces the complete appimage here. I have not included any recent changes from you for netBSD or ppc. In the beginnng, where the include files are set, is under termux it still neede to set the linux included path too? Or is it one or the other? Not yet tested under FreeBSD, and MacOS. MatN
On Monday, April 4, 2022, mat <[email protected]> wrote:
Andrew, does the attached configure.ac work for you? It produces the complete appimage here. I have not included any recent changes from you for netBSD or ppc.
In the beginnng, where the include files are set, is under termux it still neede to set the linux included path too? Or is it one or the other?
I think you can conditionalize those... https://yhbt.net/lore/all/[email protected]... ==== -AX_PATH_PROG_OR_FAIL([BASH], [bash]) +dnl FreeBSD doesn't require bash (hotplug scripts are in plain sh) +case "$host_os" in + freebsd*) ;; + *) AX_PATH_PROG_OR_FAIL([BASH], [bash]);; +esac but i wonder if host_os know about Android/termux...
Not yet tested under FreeBSD, and MacOS.
MatN
aaaand AX_ macro was xen-specific... https://fossies.org/linux/xen/m4/path_or_fail.m4 On Monday, April 4, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Monday, April 4, 2022, mat <[email protected]> wrote:
Andrew, does the attached configure.ac work for you? It produces the complete appimage here. I have not included any recent changes from you for netBSD or ppc.
In the beginnng, where the include files are set, is under termux it still neede to set the linux included path too? Or is it one or the other?
I think you can conditionalize those...
https://yhbt.net/lore/all/20170213154914.pfc5ciuycgodqktb@dhcp-3-221. uk.xensource.com/t/
==== -AX_PATH_PROG_OR_FAIL([BASH], [bash]) +dnl FreeBSD doesn't require bash (hotplug scripts are in plain sh) +case "$host_os" in + freebsd*) ;; + *) AX_PATH_PROG_OR_FAIL([BASH], [bash]);; +esac
but i wonder if host_os know about Android/termux...
Not yet tested under FreeBSD, and MacOS.
MatN
On Monday, April 4, 2022, mat <[email protected]> wrote:
Andrew, does the attached configure.ac work for you?
for some reason it downloads at configure. ac. txt and actually looks like html... can you post diff in mail body?
It produces the complete appimage here. I have not included any recent changes from you for netBSD or ppc.
In the beginnng, where the include files are set, is under termux it still neede to set the linux included path too? Or is it one or the other?
Not yet tested under FreeBSD, and MacOS.
MatN
Just feedback here - having a little trouble getting it to work, but nothing to report yet. On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
MatN, I have not been able to figure out what is wrong. See error below (from running bld_own_appimage.sh with the compiling of CinGG being commented out as it was already done several times):
[root@keystone cinelerra-5.1]# ./bld_own_appimage.sh target = x86_64 configure script options are --with-single-user --with-booby --enable-static-build configure.ac:19: installing 'cfg/compile' configure.ac:12: installing 'cfg/install-sh' configure.ac:12: installing 'cfg/missing' Makefile.am: installing 'cfg/depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of g++... gcc3 checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yeschecking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes checking for unistd.h... yes checking boost/filesystem.hpp usability... no checking boost/filesystem.hpp presence... no checking for boost/filesystem.hpp... no *configure: error: header is missing and required.* make: *** No targets specified and no makefile found. Stop. objcopy: 'makeappimage': No such file mv: cannot stat 'makeappimage': No such file or directory ./bld_own_appimage.sh: line 60: tools/makeappimage: No such file or directory
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Monday, March 28, 2022, Phyllis Smith via Cin <[email protected]> wrote:
MatN, I have not been able to figure out what is wrong. See error below (from running bld_own_appimage.sh with the compiling of CinGG being commented out as it was already done several times):
[root@keystone cinelerra-5.1]# ./bld_own_appimage.sh target = x86_64 configure script options are --with-single-user --with-booby --enable-static-build configure.ac:19: installing 'cfg/compile' configure.ac:12: installing 'cfg/install-sh' configure.ac:12: installing 'cfg/missing' Makefile.am: installing 'cfg/depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of g++... gcc3 checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yeschecking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes checking for unistd.h... yes checking boost/filesystem.hpp usability... no checking boost/filesystem.hpp presence... no checking for boost/filesystem.hpp... no *configure: error: header is missing and required.* make: *** No targets specified and no makefile found. Stop. objcopy: 'makeappimage': No such file mv: cannot stat 'makeappimage': No such file or directory ./bld_own_appimage.sh: line 60: tools/makeappimage: No such file or directory
guess boost headers not installed. I dislike libboost as dependency (due to unstable api!) but may be in this case copying relevant headers will be enough?
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, thanks! I thought having "boost" installed was sufficient, but apparently for Fedora I had to do "dnf install libbost-devel". So got past that. Let me see I really have to have "patchelf" installed or what its name is. On Sun, Mar 27, 2022 at 5:56 PM Andrew Randrianasulu < [email protected]> wrote:
On Monday, March 28, 2022, Phyllis Smith via Cin < [email protected]> wrote:
MatN, I have not been able to figure out what is wrong. See error below (from running bld_own_appimage.sh with the compiling of CinGG being commented out as it was already done several times):
[root@keystone cinelerra-5.1]# ./bld_own_appimage.sh target = x86_64 configure script options are --with-single-user --with-booby --enable-static-build configure.ac:19: installing 'cfg/compile' configure.ac:12: installing 'cfg/install-sh' configure.ac:12: installing 'cfg/missing' Makefile.am: installing 'cfg/depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of g++... gcc3 checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yeschecking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes checking for unistd.h... yes checking boost/filesystem.hpp usability... no checking boost/filesystem.hpp presence... no checking for boost/filesystem.hpp... no *configure: error: header is missing and required.* make: *** No targets specified and no makefile found. Stop. objcopy: 'makeappimage': No such file mv: cannot stat 'makeappimage': No such file or directory ./bld_own_appimage.sh: line 60: tools/makeappimage: No such file or directory
guess boost headers not installed. I dislike libboost as dependency (due to unstable api!) but may be in this case copying relevant headers will be enough?
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Yes, you really need patchelf, it is called from within. The original appimage version of linuxdeploy builds it from sources because for a appimage the executables needs to be statically linked, and the system version isn't. Indeed two boost dev libs are needed too. I dislike then, not because the API is unstable (did not know that), but because they are so bug and (for me) difficult to follow what they actually do. Maybe they can be taken out, but the filesystem one does more that I thought it does. Maybe for a next release. MatN On Sun, 27 Mar 2022 18:07:36 -0600 Phyllis Smith via Cin <[email protected]> wrote:
Andrew, thanks! I thought having "boost" installed was sufficient, but apparently for Fedora I had to do "dnf install libbost-devel". So got past that. Let me see I really have to have "patchelf" installed or what its name is.
On Sun, Mar 27, 2022 at 5:56 PM Andrew Randrianasulu < [email protected]> wrote:
On Monday, March 28, 2022, Phyllis Smith via Cin < [email protected]> wrote:
MatN, I have not been able to figure out what is wrong. See error below (from running bld_own_appimage.sh with the compiling of CinGG being commented out as it was already done several times):
[root@keystone cinelerra-5.1]# ./bld_own_appimage.sh target = x86_64 configure script options are --with-single-user --with-booby --enable-static-build configure.ac:19: installing 'cfg/compile' configure.ac:12: installing 'cfg/install-sh' configure.ac:12: installing 'cfg/missing' Makefile.am: installing 'cfg/depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of g++... gcc3 checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yeschecking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes checking for unistd.h... yes checking boost/filesystem.hpp usability... no checking boost/filesystem.hpp presence... no checking for boost/filesystem.hpp... no *configure: error: header is missing and required.* make: *** No targets specified and no makefile found. Stop. objcopy: 'makeappimage': No such file mv: cannot stat 'makeappimage': No such file or directory ./bld_own_appimage.sh: line 60: tools/makeappimage: No such file or directory
guess boost headers not installed. I dislike libboost as dependency (due to unstable api!) but may be in this case copying relevant headers will be enough?
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I was just pointed at 'filesystem' module reimplementation for c++11 and up: https://github.com/justdan96/tsMuxer/issues/577 https://github.com/gulrak/filesystem On Monday, March 28, 2022, mnieuw--- via Cin <[email protected]> wrote:
Yes, you really need patchelf, it is called from within.
The original appimage version of linuxdeploy builds it from sources because for a appimage the executables needs to be statically linked, and the system version isn't. Indeed two boost dev libs are needed too. I dislike then, not because the API is unstable (did not know that), but because they are so bug and (for me) difficult to follow what they actually do. Maybe they can be taken out, but the filesystem one does more that I thought it does. Maybe for a next release.
MatN
On Sun, 27 Mar 2022 18:07:36 -0600 Phyllis Smith via Cin <[email protected]> wrote:
Andrew, thanks! I thought having "boost" installed was sufficient, but apparently for Fedora I had to do "dnf install libbost-devel". So got past that. Let me see I really have to have "patchelf" installed or what its name is.
On Sun, Mar 27, 2022 at 5:56 PM Andrew Randrianasulu < [email protected]> wrote:
On Monday, March 28, 2022, Phyllis Smith via Cin < [email protected]> wrote:
MatN, I have not been able to figure out what is wrong. See error below (from running bld_own_appimage.sh with the compiling of CinGG being commented out as it was already done several times):
[root@keystone cinelerra-5.1]# ./bld_own_appimage.sh target = x86_64 configure script options are --with-single-user --with-booby --enable-static-build configure.ac:19: installing 'cfg/compile' configure.ac:12: installing 'cfg/install-sh' configure.ac:12: installing 'cfg/missing' Makefile.am: installing 'cfg/depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of g++... gcc3 checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yeschecking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes checking for unistd.h... yes checking boost/filesystem.hpp usability... no checking boost/filesystem.hpp presence... no checking for boost/filesystem.hpp... no *configure: error: header is missing and required.* make: *** No targets specified and no makefile found. Stop. objcopy: 'makeappimage': No such file mv: cannot stat 'makeappimage': No such file or directory ./bld_own_appimage.sh: line 60: tools/makeappimage: No such file or directory
guess boost headers not installed. I dislike libboost as dependency (due to unstable api!) but may be in this case copying relevant headers will be enough?
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Checked into GIT as is -- works GREAT! and having this available for aarch64 is added value. So far I have only tested on x86_64. I held myself back from adding 1 more comment to bld_appimage.sh but I think it needs to be added somewhere before the build of makeappimage. A comment that references the need to install boost-devel and patchelf would be appreciated. ContextHelp - CinelerraGG_Manual files - will have to be incorporated too. On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
The required packages should not be in the build scripts, because they are distro-dependent, they are in bld_prepare.sh . I have earlier sent an updated version of that which includes the needed packages. I have not tested CentOS, is anyone using that? I thought most users are on Fedora by now. If the HTML manual is copied to the proper place, it will be included in the AppImage. Or do you mean the automatic building of the manual itself? MatN On Mon, 28 Mar 2022 11:36:13 -0600 Phyllis Smith <[email protected]> wrote:
Checked into GIT as is -- works GREAT! and having this available for aarch64 is added value. So far I have only tested on x86_64. I held myself back from adding 1 more comment to bld_appimage.sh but I think it needs to be added somewhere before the build of makeappimage. A comment that references the need to install boost-devel and patchelf would be appreciated.
ContextHelp - CinelerraGG_Manual files - will have to be incorporated too.
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
The required packages should not be in the build scripts, because they are distro-dependent, they are in bld_prepare.sh .
OK, I see that now. Some of the email gets put in my Spam folder so I have to keep checking (like configure.ac).
If the HTML manual is copied to the proper place, it will be included in the AppImage.
Well, if you run bld_appimage.sh from the top after having run "make clean" those files will not be in bin/doc . This is not a problem for me at all so I think just echoing a comment to remind a user would be more than sufficient.
Maybe the attached bld_appimage.sh is better. I've updated the outdated comments, put some more descriptions in, and you can now specify if the manual must be built and included, simply by specifying the directory where is it, or not. It works fine here on Fedora_35 MatN On Mon, 28 Mar 2022 11:36:13 -0600 Phyllis Smith <[email protected]> wrote:
Checked into GIT as is -- works GREAT! and having this available for aarch64 is added value. So far I have only tested on x86_64. I held myself back from adding 1 more comment to bld_appimage.sh but I think it needs to be added somewhere before the build of makeappimage. A comment that references the need to install boost-devel and patchelf would be appreciated.
ContextHelp - CinelerraGG_Manual files - will have to be incorporated too.
On Fri, Mar 25, 2022 at 4:34 AM M Nieuwenhoven via Cin < [email protected]> wrote:
Attached is a 7z file that allows CinelerraGG in AppImage format to be built on aarch64, as well as x86 64 and 32 bit. Ir replaces linuxdeploy which was used since we switched to AppImage format a year ago, but that is not available for non-x86 platforms. The new tool called makeappimage (800k) is built automatically when needed, and is a stripped-down version of linuxdeploy: its plugin-system has been removed, and the built system switched to the much simpler autotools (like CinGG itself). It is put in a new CinGG subdirectory calls tools (but for now this is the only tool :-) ). To install, place the .7z file in the cinelerra5/cinelerra directory, and do "7z x bld_own_appimage.7z " . To use it, use the included ./bld_own_appimgage.sh . Name of the script should be changed in the future to "bld_appimage.sh" if OK for all. Make sure the appimagetool for the platform is in your path, see the note in bld_own_appimage.sh .
The script also changes the configure script options depending on the hardware it is running on. @Andrew_R, does it need extra things for termux?
MatN-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, Does this mean that the changes that you submitted and were checked into GIT in March of 2020, will no longer work? TIFF - new choices of LZW, LZWMA, *Deflate*. If so, should the Deflate be removed as an option? This is in the Native Render for Tiff. On Wed, Mar 2, 2022 at 3:26 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
try this plain diff?
On Wednesday, March 2, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Sunday, March 6, 2022, Phyllis Smith via Cin <[email protected]> wrote:
Andrew, Does this mean that the changes that you submitted and were checked into GIT in March of 2020, will no longer work?
TIFF - new choices of LZW, LZWMA, *Deflate*.
If so, should the Deflate be removed as an option? This is in the Native Render for Tiff.
there was old zlib compressor in libtiff, and there is new faster libdeflate compressor in new libtiff. Additionally to old one. so, in theory it should work as before. Can you re-test just in case?
On Wed, Mar 2, 2022 at 3:26 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
try this plain diff?
On Wednesday, March 2, 2022, Andrew Randrianasulu < [email protected]> wrote:
On Tuesday, March 1, 2022, mat via Cin <[email protected]> wrote:
The tiff problem looks to be dependent on the presence of the system of the libdeflate-dev package (Debian) or equivalent. If it is installed (and it was on my Debian_11) there is (among others) a file /usr/include/libdeflate.h . Both on aarch64(qemu) and x86_32 (native hardware, not VM). It fails on both in the same way.
On Fedora, I have installed libdeflate (was not there before), and in still builds fine, but there is no libdeflate.h and a search on dnfdragore on file names does not show it either. So I guess Fedora does not supply it.
If you compare the bld.sh log files, then on Fedora it says under "Libtiff is now configured for": "libdeflate support: no" and on both Debians it says "libdeflate support: yes"
may be force-disabling this support via configure argument for libtiff will fix build? (obvious)
So it looks like a bug in tiff.
More to test.
MatN
On Tue, 2022-03-01 at 12:50 -0700, Phyllis Smith via Cin wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_distros-multibit.AppImage ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Just now I manage to build a working CinGg AppImage for aarch64, based in CinGG 2022-02 with the deflate disable for tiff. To build an AppImage, you need three steps: - Build an AppDir with the CinGG code in it. - Then linuxdeploy figures out what more is needed, like system libraries. It copies those in the AppDir, then patches all ELF files to cater for non-standard locations. Patchelf is not part of linuxdeploy, it takes the one from the system, at least for the dynamic built linuxdeploy. - Then the "appimagetool" is run on the AppDir, which makes the actual AppImage. This tool is available for 64 and 32 bit, on x86 and arm. The main problem was linuxdeploy, which is not available for aarch64. Linuxdeploy does not build straight out of github for me, at least not so far. It uses cmake (unfamiliar for me). So I vandalised it a bit, now it builds. I did not try to build the appimagetool plugin, because that is available as a separate tool. So this linuxdeploy at the moment is not a full replacement for the standard linuxdeploy appimage, but that was not a priority. With these two and a small mode to bld_appimahe.sh, creation of the CinGG AppImage works fine. Next is to clean up and document things, so others can reproduce it at will. Also, it would be nice to convert linuxdeploy (and appimagetool) to autotools, if that succeeds then it can be fully integrated in CinGG (like the thirdparty things are).
wow, a lot of work and most importantly - it worked! Thanks a lot for effort On Monday, March 7, 2022, mnieuw--- via Cin <[email protected]> wrote:
Just now I manage to build a working CinGg AppImage for aarch64, based in CinGG 2022-02 with the deflate disable for tiff.
To build an AppImage, you need three steps: - Build an AppDir with the CinGG code in it. - Then linuxdeploy figures out what more is needed, like system libraries. It copies those in the AppDir, then patches all ELF files to cater for non-standard locations. Patchelf is not part of linuxdeploy, it takes the one from the system, at least for the dynamic built linuxdeploy. - Then the "appimagetool" is run on the AppDir, which makes the actual AppImage. This tool is available for 64 and 32 bit, on x86 and arm.
The main problem was linuxdeploy, which is not available for aarch64.
Linuxdeploy does not build straight out of github for me, at least not so far. It uses cmake (unfamiliar for me). So I vandalised it a bit, now it builds. I did not try to build the appimagetool plugin, because that is available as a separate tool. So this linuxdeploy at the moment is not a full replacement for the standard linuxdeploy appimage, but that was not a priority.
With these two and a small mode to bld_appimahe.sh, creation of the CinGG AppImage works fine.
Next is to clean up and document things, so others can reproduce it at will. Also, it would be nice to convert linuxdeploy (and appimagetool) to autotools, if that succeeds then it can be fully integrated in CinGG (like the thirdparty things are).
I think thirdparty build few things with cmake - main problem older distros have old cmake and new projects sometimes actually use new cmake features (and you probably do not want to build your own cmake - because it installs few modules for searching system-wide installed software... or at least my navie understanding of cmake tells me this - can be wrong!) --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Tuesday, March 1, 2022, Phyllis Smith via Cin <[email protected]> wrote:
Andrew, thanks for testing. If possible, in March if you create a tgz Termux build (like you did earlier and I downloaded), I can again download and put on the website for others to use.
https://cloud.mail.ru/public/JDzr/YpHkB5Qnx (for 32bit arm termux, might need libxv I send you earlier) not quite clean git build, with tsmuxer series plus few earlier cppcheck-related patches
Mat, I hope you figure out what the Tiff problem is because it will be the same for the 32-bit Debian build problem I had -- the error you get sounds the same as what I encountered before reverting to tiff 4.1.0 there.
Also, the AppImage I generate on an HP laptop with Fedora 29 - to replicate Redhat Release 8 ( CinGG-20220131-x86-64-older_ distros-multibit.AppImage <https://cinelerra-gg.org/download/images/CinGG-20220131-x86-64-older_distros-multibit.AppImage> ) has audio problems when I try running it on an AMD laptop with Fedora 32. But only if I build it with multibit. Strange so I have to try to figure this out yet.
On Tue, Mar 1, 2022 at 11:52 AM mat via Cin <[email protected]> wrote:
The 2022-02 release builds fine On Fedora_35/x86_64, but fails on Debian_11/aarch64. In thirdparty/libtiff-4.3.0/libtiff/tip_zip.c it fails because several undefined references to "libdeflate_...." . This is not something in Fedora's package manager. Will dig in further.
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
M Nieuwenhoven -
mat
-
mnieuw＠zap.a2000.nl
-
Phyllis Smith