duplicate code in cinelerra that also exists in support libraries
Please help me to understand why. This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully built this way several years ago. ----------------------------------------------- #! /bin/bash CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no ----------------------------------------------- build fails due to function redeclaration of int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap); in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source. So far the only dependency I've had to use from the thirdparty directory is libdpx since it is quite obscure and not a standard part of Debian. -Rob
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully built this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib .... I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty directory is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 11/22/25 8:41 AM, Andrew Randrianasulu wrote:
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
Thanks for the followup. So my point of confusion is that the Debian giflib version says 5.2.2 and it does include the Quant function...while the sourceforge version does not. I'd suggest that while there are multiple variants of the same version out there in the wild then the only giflib allowed during compile should be the one from the cinelerra git repo. ie forced inclusion of the git repo one. In any case I'll pull the fix once it's in the git repo. thanks!
On 11/22/25 8:41 AM, Andrew Randrianasulu wrote:
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
Thanks for the followup. So my point of confusion is that the Debian giflib version says 5.2.2 and it does include the Quant function...while the sourceforge version does not. I'd suggest that while there are multiple variants of the same version out there in the wild then the only giflib allowed during compile should be the one from the cinelerra git repo. ie forced inclusion of the git repo one. In any case I'll pull the fix once it's in the git repo. thanks! -------------------------------------------------------------------- rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src/giflib-5.2.2$ diff gif_lib.h /usr/include/gif_lib.h 214a215,223
Color table quantization
******************************************************************************/
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, const GifByteType *RedInput, const GifByteType *GreenInput, const GifByteType *BlueInput, GifByteType *OutputBuffer, GifColorType *OutputColorMap);
/****************************************************************************** rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src$ apt list libgif-dev libgif-dev/stable,now 5.2.2-1+b1 amd64 [installed] rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src$ --------------------------------------------------------------------
вс, 23 нояб. 2025 г., 00:35 Rob Prowel <[email protected]>:
On 11/22/25 8:41 AM, Andrew Randrianasulu wrote:
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
Thanks for the followup. So my point of confusion is that the Debian giflib version says 5.2.2 and it does include the Quant function...while the sourceforge version does not.
I'd suggest that while there are multiple variants of the same version out there in the wild then the only giflib allowed during compile should be the one from the cinelerra git repo. ie forced inclusion of the git repo one.
I think I run into this problem while building on FreeBSD first, where I completely disable thirdparty libs. So, proper proper way to deal with this seems to check function's existence in system giflib header and compile or not our copy according to result of test at ./configure time (if func_exist && giflib_not_from_thirdparty ...) I'll try to cook up such patch.
In any case I'll pull the fix once it's in the git repo.
thanks!
-------------------------------------------------------------------- rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src/giflib-5.2.2$
diff gif_lib.h /usr/include/gif_lib.h 214a215,223
Color table quantization
******************************************************************************/
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, const GifByteType *RedInput, const GifByteType *GreenInput, const GifByteType *BlueInput, GifByteType *OutputBuffer, GifColorType *OutputColorMap);
/****************************************************************************** rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src$ apt list libgif-dev libgif-dev/stable,now 5.2.2-1+b1 amd64 [installed] rprowel@files:~/programming/cingg/cinelerra-5.1/thirdparty/src$ --------------------------------------------------------------------
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also. ??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"??? On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully built this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty directory is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Andrew-R/Rob, AND the "const" were not in giflib 5.1.6 or in 5.2.1 but are now in 5.2.2. Adding the int definition to Cinelerra filegif.C must have been needed to fix something or for a speedup? On Tue, Nov 25, 2025 at 11:14 AM Phyllis Smith <[email protected]> wrote:
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also.
??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"???
On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully built this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty directory is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
вт, 25 нояб. 2025 г., 22:28 Phyllis Smith <[email protected]>:
Andrew-R/Rob, AND the "const" were not in giflib 5.1.6 or in 5.2.1 but are now in 5.2.2. Adding the int definition to Cinelerra filegif.C must have been needed to fix something or for a speedup?
As far as I remember I just run into fact filegif was not buildable on FreeBSD back in this time, so I added whole function so it compiled for me on all systems. Sorry, I am a bit distracted, need to move few things out of too full hdd, respin some Debian and FreeBSD VMs and see how it behaves ...
On Tue, Nov 25, 2025 at 11:14 AM Phyllis Smith <[email protected]> wrote:
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also.
??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"???
On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully built this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty
directory
is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Sorry, I am a bit distracted, need to move few things
Andrew, that is OK - just keep working on what you need to. *Rob*, unless you vehemently object, I propose adding const in the Cinelerra code. You will see that even the current giflib file, getarg.h (support routine for the giflib utilities), was not updated when quantize.c was to include the const.
... Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Further evaluation reveals the cause of the duplication in Cinelerra in the NEWS published in the giflib directory: 5.1.6 giflib NEWS:
* QuantizeBuffer() has been returned to the core library as GifQuantizeBuffer() - turns out some important applications (*notably mplayer*) were using it.
5.2.1 giflib NEWS quote below:
Version 5.2.0 =============
The undocumented and deprecated GifQuantizeBuffer() entry point has been moved to the util library to reduce libgif size and attack
surface. *Applications needing this function are couraged to* link the
util library or *make their own copy.*
Bottom line -- commit adding the giflib getarg.h code to Cinelerra was copied as they suggested and I think we need to continue doing this because the giflib team might change it again. This gives us the ability to preserve the current capability while at the same time allows those who prefer to use the distro libraries over the in-source thirdparty ones. I will test and await Rob's agreement. On Tue, Nov 25, 2025 at 12:35 PM Andrew Randrianasulu < [email protected]> wrote:
вт, 25 нояб. 2025 г., 22:28 Phyllis Smith <[email protected]>:
Andrew-R/Rob, AND the "const" were not in giflib 5.1.6 or in 5.2.1 but are now in 5.2.2. Adding the int definition to Cinelerra filegif.C must have been needed to fix something or for a speedup?
As far as I remember I just run into fact filegif was not buildable on FreeBSD back in this time, so I added whole function so it compiled for me on all systems.
Sorry, I am a bit distracted, need to move few things out of too full hdd, respin some Debian and FreeBSD VMs and see how it behaves ...
On Tue, Nov 25, 2025 at 11:14 AM Phyllis Smith <[email protected]> wrote:
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also.
??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"???
On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully
built
this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty
directory
is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
вт, 25 нояб. 2025 г., 23:46 Phyllis Smith <[email protected]>:
Sorry, I am a bit distracted, need to move few things
Andrew, that is OK - just keep working on what you need to.
*Rob*, unless you vehemently object, I propose adding const in the Cinelerra code. You will see that even the current giflib file, getarg.h (support routine for the giflib utilities), was not updated when quantize.c was to include the const.
... Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Further evaluation reveals the cause of the duplication in Cinelerra in the NEWS published in the giflib directory: 5.1.6 giflib NEWS:
* QuantizeBuffer() has been returned to the core library as GifQuantizeBuffer() - turns out some important applications (*notably mplayer*) were using it.
5.2.1 giflib NEWS quote below:
Version 5.2.0 =============
The undocumented and deprecated GifQuantizeBuffer() entry point has been moved to the util library to reduce libgif size and attack
surface. *Applications needing this function are couraged to* link the
util library or *make their own copy.*
Bottom line -- commit adding the giflib getarg.h code to Cinelerra was copied as they suggested and I think we need to continue doing this because the giflib team might change it again.
This gives us the ability to preserve the current capability while at the same time allows those who prefer to use the distro libraries over the in-source thirdparty ones. I will test and await Rob's agreement.
Can you instead test attached patch? It should test for existence of this function in system's giflib headers and set define depending on do we want to compile with thirdparty's giflib or without Please test both usual thirdparty build on new and old systems, and build without thirdparty on Debian 13 where such symbol must be present (patched into) giflib header, as far as I understand. I tested it on dynamic termux build and here it works, but this only covers 1 out of 4 possible combinations ...
On Tue, Nov 25, 2025 at 12:35 PM Andrew Randrianasulu < [email protected]> wrote:
вт, 25 нояб. 2025 г., 22:28 Phyllis Smith <[email protected]>:
Andrew-R/Rob, AND the "const" were not in giflib 5.1.6 or in 5.2.1 but are now in 5.2.2. Adding the int definition to Cinelerra filegif.C must have been needed to fix something or for a speedup?
As far as I remember I just run into fact filegif was not buildable on FreeBSD back in this time, so I added whole function so it compiled for me on all systems.
Sorry, I am a bit distracted, need to move few things out of too full hdd, respin some Debian and FreeBSD VMs and see how it behaves ...
On Tue, Nov 25, 2025 at 11:14 AM Phyllis Smith <[email protected]> wrote:
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also.
??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"???
On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote:
Please help me to understand why.
This is my make-config and I'm building from scratch on Debian-13(trixie). I've re-run autoconf and aclocal to support the newer macros/features. Also note that I'm leveraging the distro libraries over the in-source thirdparty ones. I have sucessfully
built
this way several years ago.
----------------------------------------------- #! /bin/bash
CUDA_PATH=/usr \ ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=8 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no -----------------------------------------------
build fails due to function redeclaration of
int GifQuantizeBuffer(unsigned int Width, unsigned int Height, int *ColorMapSize, GifByteType * RedInput, GifByteType * GreenInput, GifByteType * BlueInput, GifByteType * OutputBuffer, GifColorType * OutputColorMap);
in filegif.h and filegif.C...but this method also exists in the thirdparty library giflib. The reason it fails is that in the library the pointers are const (as they should be) but in the duplicated code under cinelerra directory they are not...and simply adding const in the included code is not a fix, IMHO. Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
So far the only dependency I've had to use from the thirdparty
directory
is libdpx since it is quite obscure and not a standard part of Debian.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Andrew-R, OK will test on where I usually build, Fedora 32 and 42, Ubuntu 16, Debian 9 and 11 - 32 bit. I do not have Debian 13 so Rob can do that. On Tue, Nov 25, 2025 at 2:05 PM Andrew Randrianasulu < [email protected]> wrote:
вт, 25 нояб. 2025 г., 23:46 Phyllis Smith <[email protected]>:
Sorry, I am a bit distracted, need to move few things
Andrew, that is OK - just keep working on what you need to.
*Rob*, unless you vehemently object, I propose adding const in the Cinelerra code. You will see that even the current giflib file, getarg.h (support routine for the giflib utilities), was not updated when quantize.c was to include the const.
... Lets please evaluate why the library code was duplicated within the project source in the first place. giflib is not only available under the thirdparty directory, but is a common library on most linux distros. It seems odd that it's both referenced from the library AND duplicated in-source.
Further evaluation reveals the cause of the duplication in Cinelerra in the NEWS published in the giflib directory: 5.1.6 giflib NEWS:
* QuantizeBuffer() has been returned to the core library as GifQuantizeBuffer() - turns out some important applications (*notably mplayer*) were using it.
5.2.1 giflib NEWS quote below:
Version 5.2.0 =============
The undocumented and deprecated GifQuantizeBuffer() entry point has been moved to the util library to reduce libgif size and attack
surface. *Applications needing this function are couraged to* link the
util library or *make their own copy.*
Bottom line -- commit adding the giflib getarg.h code to Cinelerra was copied as they suggested and I think we need to continue doing this because the giflib team might change it again.
This gives us the ability to preserve the current capability while at the same time allows those who prefer to use the distro libraries over the in-source thirdparty ones. I will test and await Rob's agreement.
Can you instead test attached patch?
It should test for existence of this function in system's giflib headers and set define depending on do we want to compile with thirdparty's giflib or without
Please test both usual thirdparty build on new and old systems, and build without thirdparty on Debian 13 where such symbol must be present (patched into) giflib header, as far as I understand.
I tested it on dynamic termux build and here it works, but this only covers 1 out of 4 possible combinations ...
On Tue, Nov 25, 2025 at 12:35 PM Andrew Randrianasulu < [email protected]> wrote:
вт, 25 нояб. 2025 г., 22:28 Phyllis Smith <[email protected]>:
Andrew-R/Rob, AND the "const" were not in giflib 5.1.6 or in 5.2.1 but are now in 5.2.2. Adding the int definition to Cinelerra filegif.C must have been needed to fix something or for a speedup?
As far as I remember I just run into fact filegif was not buildable on FreeBSD back in this time, so I added whole function so it compiled for me on all systems.
Sorry, I am a bit distracted, need to move few things out of too full hdd, respin some Debian and FreeBSD VMs and see how it behaves ...
On Tue, Nov 25, 2025 at 11:14 AM Phyllis Smith <[email protected]> wrote:
Andrew-R/Rob, FYI - 27 Feb 2019 was a commit for "gif rework" and this appears to be the first date the QuantizeBuffer was used in filegif.C, BUT not yet defined as "int GIfQuantizeBuffer..." In the ReleaseNotes.pdf is stated:
Gif native capability has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists.
I have verified that render to the GIF formats became available at/after the 27 Feb 2019 date. QuantizeBuffer usage was in the giflib library before and after that time, but the "int" definition was added in the Cinelerra filegif.C on 28 Feb 2020 as in:
diff --git a/cinelerra-5.1/cinelerra/filegif.C b/cinelerra-5.1/cinelerra/filegif.C index 6f4e3e43d800a28dd4cf57b1b45231b73d04df77..bb26762bef07094251db75deeaea1b000230bcc6 100644 (file)
--- a/cinelerra-5.1/cinelerra/filegif.C
+++ b/cinelerra-5.1/cinelerra/filegif.C @@ -32,6 +32,14 @@ #include <fcntl.h> #include <string.h>
+//from "getarg.h" +extern "C" +int GifQuantizeBuffer(unsigned int Width, unsigned int Height, + int *ColorMapSize, GifByteType * RedInput, + GifByteType * GreenInput, GifByteType * BlueInput, + GifByteType * OutputBuffer, + GifColorType * OutputColorMap);
+
FileGIF::FileGIF(Asset *asset, File *file) : FileBase(asset, file)
No help from the comment included with the commit or from the release notes (frowny face). Giflib was updated from 5.1.6 to 5.2.1 at that date also.
??? Can this commit be reversed? or since we do not know why it was included, should we just add the "const"???
On Sat, Nov 22, 2025 at 6:37 AM Andrew Randrianasulu < [email protected]> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <[email protected]> wrote: > > Please help me to understand why. > > This is my make-config and I'm building from scratch on > Debian-13(trixie). I've re-run autoconf and aclocal to support the > newer macros/features. Also note that I'm leveraging the distro > libraries over the in-source thirdparty ones. I have sucessfully built > this way several years ago. > > > ----------------------------------------------- > #! /bin/bash > > CUDA_PATH=/usr \ > ./configure \ > --prefix=/sharebin/cingg2511 \ > --with-cuda \ > --with-nv \ > --with-gl \ > --with-xv \ > --with-jobs=8 \ > --with-alsa \ > --enable-audiofile \ > --with-thirdparty=no > ----------------------------------------------- > > build fails due to function redeclaration of > > int GifQuantizeBuffer(unsigned int Width, > unsigned int Height, > int *ColorMapSize, > GifByteType * RedInput, > GifByteType * GreenInput, > GifByteType * BlueInput, > GifByteType * OutputBuffer, > GifColorType * OutputColorMap); > > in filegif.h and filegif.C...but this method also exists in the > thirdparty library giflib. The reason it fails is that in the library > the pointers are const (as they should be) but in the duplicated code > under cinelerra directory they are not...and simply adding const in the > included code is not a fix, IMHO. Lets please evaluate why the library > code was duplicated within the project source in the first place. > giflib is not only available under the thirdparty directory, but is a > common library on most linux distros. It seems odd that it's both > referenced from the library AND duplicated in-source.
Because this function at some point disappeared from official giflib ....
I guess adding version defines around this piece of code will be correct course of action.
> > So far the only dependency I've had to use from the thirdparty directory > is libdpx since it is quite obscure and not a standard part of Debian. > > -Rob > > > > > _______________________________________________ > Cin mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 11/25/25 4:05 PM, Andrew Randrianasulu wrote:
Can you instead test attached patch?
It should test for existence of this function in system's giflib headers and set define depending on do we want to compile with thirdparty's giflib or without
Please test both usual thirdparty build on new and old systems, and build without thirdparty on Debian 13 where such symbol must be present (patched into) giflib header, as far as I understand.
I tested it on dynamic termux build and here it works, but this only covers 1 out of 4 possible combinations ...
As aluded to, out in the wild even the consistent library version number has inconsistent, interfaces between sources. Until upstream gets their act together, the prudent thing is probly to test compile and set flags as AR suggested. Please let me know when the patch is pushed and what commit it exists under and I will merge and test for Debian 13. -Rob
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit: commit 0bb5444770e3db55113e4c012d0a1074e30f4475 Thanks to Rob for pointing out this deficiency and Andrew for addressing. On Tue, Nov 25, 2025 at 2:20 PM Rob Prowel <[email protected]> wrote:
On 11/25/25 4:05 PM, Andrew Randrianasulu wrote:
Can you instead test attached patch?
It should test for existence of this function in system's giflib headers and set define depending on do we want to compile with thirdparty's giflib or without
Please test both usual thirdparty build on new and old systems, and build without thirdparty on Debian 13 where such symbol must be present (patched into) giflib header, as far as I understand.
I tested it on dynamic termux build and here it works, but this only covers 1 out of 4 possible combinations ...
As aluded to, out in the wild even the consistent library version number has inconsistent, interfaces between sources. Until upstream gets their act together, the prudent thing is probly to test compile and set flags as AR suggested.
Please let me know when the patch is pushed and what commit it exists under and I will merge and test for Debian 13.
-Rob
On 11/26/25 4:25 PM, Phyllis Smith wrote:
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit:
commit 0bb5444770e3db55113e4c012d0a1074e30f4475
When I have a chance in the next few days I will attempt build under Debian13 using distro libraries. Understand that I haven't yet done a successful build under Debian13, but have been addressing each library problem encountered as I attempt to build iteratively.
On 11/26/25 4:25 PM, Phyllis Smith wrote:
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit:
commit 0bb5444770e3db55113e4c012d0a1074e30f4475
Thanks to Rob for pointing out this deficiency and Andrew for addressing.
two things: 1) I thought the patch was going to do a an autoconf test to determine the existence of the quant function but it does not. I can force the issue with CXXFLAGS=-DHAVE_GIFLIB_QUANTIZE but we can defer that for the moment. 2) your filegif.C line-238: #endif is on the wrong line. It partially truncates the function and causes a compilation failure. It should be moved to line 251. So there is no confusion, this is my make-config under Deb-13 ------------------------------------------------------------------------- #! /bin/bash export CFLAGS="-ggdb -O0 -DHAVE_GIFLIB_QUANTIZE" export CXXFLAGS=$CFLAGS export CUDA_PATH=/usr aclocal libtoolize automake --add-missing autoconf ./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=12 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no \
ср, 3 дек. 2025 г., 11:34 Rob Prowel <[email protected]>:
On 11/26/25 4:25 PM, Phyllis Smith wrote:
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit:
commit 0bb5444770e3db55113e4c012d0a1074e30f4475
Thanks to Rob for pointing out this deficiency and Andrew for addressing.
two things:
1) I thought the patch was going to do a an autoconf test to determine the existence of the quant function but it does not. I can force the issue with CXXFLAGS=-DHAVE_GIFLIB_QUANTIZE but we can defer that for the moment.
2) your filegif.C line-238: #endif is on the wrong line. It partially truncates the function and causes a compilation failure. It should be moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
So there is no confusion, this is my make-config under Deb-13 -------------------------------------------------------------------------
#! /bin/bash
export CFLAGS="-ggdb -O0 -DHAVE_GIFLIB_QUANTIZE" export CXXFLAGS=$CFLAGS export CUDA_PATH=/usr
aclocal libtoolize automake --add-missing autoconf
there should be ./autogen.sh for this ...
./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=12 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no \
Hopefully attached patch should fix compilation? ср, 3 дек. 2025 г., 12:07 Andrew Randrianasulu <[email protected]>:
ср, 3 дек. 2025 г., 11:34 Rob Prowel <[email protected]>:
On 11/26/25 4:25 PM, Phyllis Smith wrote:
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit:
commit 0bb5444770e3db55113e4c012d0a1074e30f4475
Thanks to Rob for pointing out this deficiency and Andrew for addressing.
two things:
1) I thought the patch was going to do a an autoconf test to determine the existence of the quant function but it does not. I can force the issue with CXXFLAGS=-DHAVE_GIFLIB_QUANTIZE but we can defer that for the moment.
2) your filegif.C line-238: #endif is on the wrong line. It partially truncates the function and causes a compilation failure. It should be moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
So there is no confusion, this is my make-config under Deb-13 -------------------------------------------------------------------------
#! /bin/bash
export CFLAGS="-ggdb -O0 -DHAVE_GIFLIB_QUANTIZE" export CXXFLAGS=$CFLAGS export CUDA_PATH=/usr
aclocal libtoolize automake --add-missing autoconf
there should be ./autogen.sh for this ...
./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=12 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no \
This patch has been checked into CinGG source. In addition, I added the "const" to the red, green, and blue colors in filegif.C because that is better defined. Thank you Andrew and Rob. Reminder to see changes: https://git.cinelerra-gg.org/?p=goodguy/cinelerra.git;a=summary to clone: git clone https://git.cinelerra-gg.org/goodguy/cinelerra.git On Wed, Dec 3, 2025 at 2:15 AM Andrew Randrianasulu <[email protected]> wrote:
Hopefully attached patch should fix compilation?
ср, 3 дек. 2025 г., 12:07 Andrew Randrianasulu <[email protected]>:
ср, 3 дек. 2025 г., 11:34 Rob Prowel <[email protected]>:
On 11/26/25 4:25 PM, Phyllis Smith wrote:
Rob/Andrew - Tested my usual builds with Andrew's patch and then rendered a Gif Sequence with no problems. Not sure if that includes all necessary tests concerning Gif but hope so. I would have liked to test by building without thirdparty but I do not have sufficient disk space to install all of the Operating System libraries to use instead of the thirdparty ones. It has been checked into GIT with the following commit:
commit 0bb5444770e3db55113e4c012d0a1074e30f4475
Thanks to Rob for pointing out this deficiency and Andrew for addressing.
two things:
1) I thought the patch was going to do a an autoconf test to determine the existence of the quant function but it does not. I can force the issue with CXXFLAGS=-DHAVE_GIFLIB_QUANTIZE but we can defer that for the moment.
2) your filegif.C line-238: #endif is on the wrong line. It partially truncates the function and causes a compilation failure. It should be moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
So there is no confusion, this is my make-config under Deb-13 -------------------------------------------------------------------------
#! /bin/bash
export CFLAGS="-ggdb -O0 -DHAVE_GIFLIB_QUANTIZE" export CXXFLAGS=$CFLAGS export CUDA_PATH=/usr
aclocal libtoolize automake --add-missing autoconf
there should be ./autogen.sh for this ...
./configure \ --prefix=/sharebin/cingg2511 \ --with-cuda \ --with-nv \ --with-gl \ --with-xv \ --with-jobs=12 \ --with-alsa \ --enable-audiofile \ --with-thirdparty=no \
On 12/3/25 4:07 AM, Andrew Randrianasulu wrote:
truncates the function and causes a compilation failure. It should be moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
there should be ./autogen.sh for this ...
I manually edited the file before sending last email, so if patch is valid then push it to git, but I still don't have a working build. additional issues are 1) libdxp is extremely obscure and I'm using system libraries so I manually installed it in /usr/local. However the cinelerra build system is having trouble with it when linked as a system lib. the class inheritance breaks at linking because it cannot find the InStream base class. I've since removed it from the build with --without-libdpx 2) Im on plugins now and cuda doesn't seems to be well supported. It still refers to unsupported compute levels, and there are missing includes required to build the cuda plugins. I doubt anyone is using it so I'd suggest removal of cuda options until it is better debugged. --- OK so I can build but "make install" fails now with test ! -f db/utils/new_db || cp -a db/utils/new_db "bin/cin_db" cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/bin" \ zmpeg3{cc2txt,ifochk} cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/lib/cin" \ hveg2enc mpeg2enc mplex mplexlo *** Error - inst.sh mpeg2enc in /sharebin/cingg2511/lib/cin failed. make: *** [Makefile:1081: zmp_install] Error 1 rprowel@files:~/programming/cingg/cinelerra-5.1$ ll /usr/bin/mpeg2enc -rwxr-xr-x 1 root root 49744 Oct 29 2024 /usr/bin/mpeg2enc I suppose this would be less of a problem if it were at the end of the installation procedure but considering the plugins aren't installed at that point, it is broken.
ср, 3 дек. 2025 г., 13:16 Rob Prowel <[email protected]>:
On 12/3/25 4:07 AM, Andrew Randrianasulu wrote:
truncates the function and causes a compilation failure. It should
be
moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
there should be ./autogen.sh for this ...
I manually edited the file before sending last email, so if patch is valid then push it to git, but I still don't have a working build. additional issues are
1) libdxp is extremely obscure and I'm using system libraries so I manually installed it in /usr/local. However the cinelerra build system is having trouble with it when linked as a system lib. the class inheritance breaks at linking because it cannot find the InStream base class. I've since removed it from the build with --without-libdpx
Hopefully ffmpeg/libavcodec still can be used to read dpx files ... Sorry, I am not really programmer so I doubt I can fix this (I may try at some point).
2) Im on plugins now and cuda doesn't seems to be well supported. It still refers to unsupported compute levels, and there are missing includes required to build the cuda plugins. I doubt anyone is using it so I'd suggest removal of cuda options until it is better debugged.
Well, it was working with specific version of CUDA, hopefully someone can recall exact version. I prefer NOT to disable/remove things because putting them back together is also error-prone work.
---
OK so I can build but "make install" fails now with
test ! -f db/utils/new_db || cp -a db/utils/new_db "bin/cin_db" cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/bin" \ zmpeg3{cc2txt,ifochk} cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/lib/cin" \ hveg2enc mpeg2enc mplex mplexlo *** Error - inst.sh mpeg2enc in /sharebin/cingg2511/lib/cin failed. make: *** [Makefile:1081: zmp_install] Error 1
Sounds like "make install" having trouble installing into custom prefix ? Do you have mjpegtools-dev installed? I think whole internal mpeg encoder depend on it .... You can look at scripts in blds/ directory, they disable some things. I think DVB input depend on internal mpeg2 engine too, so if you disable that (for some reason ) then you probably want to disable some of v4l2 inputs. Sorry, not all of it is automated, a lot of options accumulated over time (and more to come, with Vulkan/HDR support) but usually build without thirdparty works because I build on *BSD VMs like that ...
rprowel@files:~/programming/cingg/cinelerra-5.1$ ll /usr/bin/mpeg2enc -rwxr-xr-x 1 root root 49744 Oct 29 2024 /usr/bin/mpeg2enc
I suppose this would be less of a problem if it were at the end of the installation procedure but considering the plugins aren't installed at that point, it is broken.
ср, 3 дек. 2025 г., 15:55 Andrew Randrianasulu <[email protected]>:
ср, 3 дек. 2025 г., 13:16 Rob Prowel <[email protected]>:
On 12/3/25 4:07 AM, Andrew Randrianasulu wrote:
truncates the function and causes a compilation failure. It should
be
moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
there should be ./autogen.sh for this ...
I manually edited the file before sending last email, so if patch is valid then push it to git, but I still don't have a working build. additional issues are
1) libdxp is extremely obscure and I'm using system libraries so I manually installed it in /usr/local. However the cinelerra build system is having trouble with it when linked as a system lib. the class inheritance breaks at linking because it cannot find the InStream base class. I've since removed it from the build with --without-libdpx
Hopefully ffmpeg/libavcodec still can be used to read dpx files ...
Sorry, I am not really programmer so I doubt I can fix this (I may try at some point).
2) Im on plugins now and cuda doesn't seems to be well supported. It still refers to unsupported compute levels, and there are missing includes required to build the cuda plugins. I doubt anyone is using it so I'd suggest removal of cuda options until it is better debugged.
Well, it was working with specific version of CUDA, hopefully someone can recall exact version.
I prefer NOT to disable/remove things because putting them back together is also error-prone work.
---
OK so I can build but "make install" fails now with
test ! -f db/utils/new_db || cp -a db/utils/new_db "bin/cin_db" cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/bin" \ zmpeg3{cc2txt,ifochk} cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/lib/cin" \ hveg2enc mpeg2enc mplex mplexlo *** Error - inst.sh mpeg2enc in /sharebin/cingg2511/lib/cin failed. make: *** [Makefile:1081: zmp_install] Error 1
Sounds like "make install" having trouble installing into custom prefix ?
Do you have mjpegtools-dev installed? I think whole internal mpeg encoder depend on it ....
You can look at scripts in blds/ directory, they disable some things. I think DVB input depend on internal mpeg2 engine too, so if you disable that (for some reason ) then you probably want to disable some of v4l2 inputs. Sorry, not all of it is automated, a lot of options accumulated over time (and more to come, with Vulkan/HDR support) but usually build without thirdparty works because I build on *BSD VMs like that ...
Ah, checked on Termux (where I build without thirdparty, there is no system mjpegtools but libzmpeg still builds) and I think I made patch that should at least fix install part of the problem by taking different Makefile target if thirdparty build was not done (so no mjpegtools get build there and no mpeg2enc/mplex get build and installed in bin consequently) Runtime still might have problem if you attempt to use MPEG video (m2v) encoding setting, I wonder if making symlinks to where cingg install other progs might be needed? But for now can you test (apply with "git am", remove by using " git reset --hard prev_commit") attached patch for your scenario ?
rprowel@files:~/programming/cingg/cinelerra-5.1$ ll /usr/bin/mpeg2enc -rwxr-xr-x 1 root root 49744 Oct 29 2024 /usr/bin/mpeg2enc
I suppose this would be less of a problem if it were at the end of the installation procedure but considering the plugins aren't installed at that point, it is broken.
Well, it was working with specific version of CUDA, hopefully someone can recall exact version.
It was version 10 at the time and now Nvidia is at version 13. On Wed, Dec 3, 2025 at 5:56 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
ср, 3 дек. 2025 г., 13:16 Rob Prowel <[email protected]>:
On 12/3/25 4:07 AM, Andrew Randrianasulu wrote:
truncates the function and causes a compilation failure. It should
be
moved to line 251.
Ah, thanks. Will fix and send fix to mail list.
there should be ./autogen.sh for this ...
I manually edited the file before sending last email, so if patch is valid then push it to git, but I still don't have a working build. additional issues are
1) libdxp is extremely obscure and I'm using system libraries so I manually installed it in /usr/local. However the cinelerra build system is having trouble with it when linked as a system lib. the class inheritance breaks at linking because it cannot find the InStream base class. I've since removed it from the build with --without-libdpx
Hopefully ffmpeg/libavcodec still can be used to read dpx files ...
Sorry, I am not really programmer so I doubt I can fix this (I may try at some point).
2) Im on plugins now and cuda doesn't seems to be well supported. It still refers to unsupported compute levels, and there are missing includes required to build the cuda plugins. I doubt anyone is using it so I'd suggest removal of cuda options until it is better debugged.
Well, it was working with specific version of CUDA, hopefully someone can recall exact version.
I prefer NOT to disable/remove things because putting them back together is also error-prone work.
---
OK so I can build but "make install" fails now with
test ! -f db/utils/new_db || cp -a db/utils/new_db "bin/cin_db" cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/bin" \ zmpeg3{cc2txt,ifochk} cd bin; /6TB/storage/programming/cingg/cinelerra-5.1/inst.sh "/sharebin/cingg2511/lib/cin" \ hveg2enc mpeg2enc mplex mplexlo *** Error - inst.sh mpeg2enc in /sharebin/cingg2511/lib/cin failed. make: *** [Makefile:1081: zmp_install] Error 1
Sounds like "make install" having trouble installing into custom prefix ?
Do you have mjpegtools-dev installed? I think whole internal mpeg encoder depend on it ....
You can look at scripts in blds/ directory, they disable some things. I think DVB input depend on internal mpeg2 engine too, so if you disable that (for some reason ) then you probably want to disable some of v4l2 inputs. Sorry, not all of it is automated, a lot of options accumulated over time (and more to come, with Vulkan/HDR support) but usually build without thirdparty works because I build on *BSD VMs like that ...
rprowel@files:~/programming/cingg/cinelerra-5.1$ ll /usr/bin/mpeg2enc -rwxr-xr-x 1 root root 49744 Oct 29 2024 /usr/bin/mpeg2enc
I suppose this would be less of a problem if it were at the end of the installation procedure but considering the plugins aren't installed at that point, it is broken.
_______________________________________________
Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Rob Prowel