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] >> >
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
