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 < randrianasulu@gmail.com> wrote:
вт, 25 нояб. 2025 г., 23:46 Phyllis Smith <phylsmith2017@gmail.com>:
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 < randrianasulu@gmail.com> wrote:
вт, 25 нояб. 2025 г., 22:28 Phyllis Smith <phylsmith2017@gmail.com>:
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 <phylsmith2017@gmail.com> 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 < randrianasulu@gmail.com> wrote:
On Tue, Nov 18, 2025 at 8:19 PM Rob Prowel <rprowel@comcast.net> 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 -- cin@lists.cinelerra-gg.org > To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org _______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org