вт, 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]
