gimp-gap PKGBUILD got a problem

ElMastro · 2025-01-12 22:56:03

Hello, I would like to fix the gimp-gap PKGBUILD.

  make -j1

comes out with

libavfilter/libmpcodecs/vf_screenshot.c:137:29: error: passing argument 2 of ‘sws_scale’ from incompatible pointer type [-Wincompatible-pointer-types]
  137 |     sws_scale(priv->ctx, mpi->planes, mpi->stride, 0, priv->dh, dst, dst_stride);
      |                          ~~~^~~~~~~~
      |                             |
      |                             unsigned char **

And the same error happens again after that passing "src" on line 160.

First thing: I couldn't get any documentation to understand this and I can't even figure from where mpi comes out.
Second (and maybe more important: My version is still working, but the source is abandoned, there is no official source and as long as I know the person that made this is impossible to found out (email seems to have been deleted or something like that). There is still sense in fixing this?
What I mean is, the code could be ported on github and made work (if there is a fix), but wouldn't this be like *stolen*?

Thank you in advance for your time and your patience

twelveeighty · 2025-01-13 00:27:14

Please use the Report button and ask a moderator to move your post to AUR Issues, gimp-gap is not in extra.

As for your "stolen" concern: that all depends on the gimp-gap license. Assuming it's open-sourced properly, you can host its code elsewhere.

WorMzy · 2025-01-13 00:48:27

Mod note: moving to AUR Issues.

ElMastro · 2025-01-14 00:01:45

I apologize for my mistake.
However, as far as I know, the package should be under GPL version 3.

twelveeighty · 2025-01-14 01:19:19

It looks like it's technically "GPL-2.0-or-later" so GPLv3 should be OK for modifications. It's bizarre they didn't have a LICENSE file in the repo, I just checked some of the .c files for the header. If you want to take it on and host it on Github, then the project should probably be forked + renamed to make sure people are not bothering the original devs. The license allows for that, as long as you don't modify the license on the existing files or re-license the project to an compatible license to GPLv2/3.

However, since this project was archived 6 years ago, I would just abandon the AUR package; trying to maintain it you're probably in for a lot of pain dealing with dependencies and compiler migration.

I couldn't find any obvious successor for gimp-gap, did GIMP simply abandon animations, or was it taken over by another project?

Lone_Wolf · 2025-01-14 10:40:31

Have you checked it the functionality is present in the soon-to-be-released gimp 3 ?

ElMastro · 2025-01-15 01:50:06

twelveeighty wrote:

I couldn't find any obvious successor for gimp-gap, did GIMP simply abandon animations, or was it taken over by another project?

I have no idea. I never heard of another project. I wrote half a dozen of people who worked in it, no one eve answered. It seems like they vanished.

Lone_Wolf wrote:

Have you checked it the functionality is present in the soon-to-be-released gimp 3 ?

No idea. I have Gimp 2.10.38-5 and here it works. I would be tempted to copy all the *.mo files and make a package, but I think it would work only fo my architecture (x86_64)

Sad as it sounds, it really seems this is a dead end for it, at least if some documentation doesn't spawn out.

mackin_cheese · 2025-01-15 04:01:01

ElMastro wrote:

but I think it would work only fo my architecture (x86_64)

that shouldn't be an issue then, Arch Linux only supports x86_64 so that package should be good to go.

twelveeighty · 2025-01-15 15:35:57

Maybe post on the GIMP extension forum. That forums looks active and you may get someone on the inside to comment on whether gimp-gap is a dead end, or replaced by a different plugin in v3. The release notes for v3 don't mention animations at all, but perhaps there's a plugin in the works for it?

If not, it could be a decent development project if you want to take it on and fork the original project. That's assuming you do not have to refactor the entire thing, of course; but, then again, if you're into that, there's nothing wrong with that either.

ElMastro · 2025-01-16 01:32:51

twelveeighty wrote:

Maybe post on the GIMP extension forum.

Nice, I am doing it.

ElMastro · 2025-02-02 01:38:17

Truth is I have done it, but nothing came out (https://www.gimp-forum.net/Thread-Information-about-GAP).

What could be done would be to build the "package" with fakepkg, move it to github and downloads the single files as plugins.
I am not sure about what would happen when Gimp upgrades.

loqs · 2025-02-02 20:28:54

You fixed the build failure?

ElMastro · 2025-02-05 00:51:10

@loqs, no, I didn't. What I mean is that we can repackage it and I have asked around as suggested. I "could" try to fix it, but before that I need to understand myself what this pointer is about, and now I can't even get from which library it comes from. Sorry, I am a bit slow right now, it's a busy period

a821 · 2025-02-05 08:11:34

Maybe try adding `-fpermissive` to CFLAGS?

twelveeighty · 2025-02-05 16:27:26

-fpermissive made me take another look at the upstream code: OP: you might be in deeper water than I originally thought. The gimp-gap repo actually includes a tar.gz of ffmpeg, fixed at version 0.7.11. Upstream ffmpeg is at 7.x. It's inside the ancient ffmpeg library where that particular error occurs.

To properly "fix" gimp-gap, you should probably first look at refactoring its ffmpeg dependency to use the current version instead, otherwise you're maintaining two code bases.

ElMastro · 2025-02-06 02:06:06

@twelveeighty so what we are talking about is modifying ALL the dependency about ffmpeg. This seems to be a work for many people.

What I was hoping for, was that we could modify this *mpi struct in gimp-gap/src/gimp-gap/extern_libs/ffmpeg/libavfilter/libmpcodecs/mp_image.h, change this unsigned char* to this "const uint8_t *" (whatever this mean), see if this trick would make the compiler work, and after that decide what is best to do.

(Sorry if I am saying foolish things, this is just not my cup of tea as you can image)

twelveeighty · 2025-02-06 16:25:06

Well, -fpermissive effectively would allow that pointer conversion without having to touch the code. The error looks to be for a double pointer (**), though, be careful if you want to change that code itself.

The problem remains is that you're "fixing" an error in ffmpeg, an upstream library's source file from many versions ago that probably has that problem fixed many years ago in a later version. What happens if you replace ffmpeg 0.7.11 with ffmpeg 7.x? How many errors do you get? If you're lucky it may not be as bad as you think it is.

ElMastro · 2025-02-06 23:06:05

twelveeighty wrote:

What happens if you replace ffmpeg 0.7.11 with ffmpeg 7.x?

Nothing, just you have to rename the archive, and config and make come out with the same results.

mp_image.h header is in the /libavfilter/libmpcodecs/ folder, it's created by PKGBUILD. At this point it seems that "-fpermissive" solves the problem, but I would like to change this line in mp_image.h (to me it appears to be the C structure that host the frame). If this works, we got the source code for all the distros

twelveeighty · 2025-02-07 02:11:18

Well - that mp_image.h is old - I *think* that got replaced by mpv at some point (or perhaps forked and both mplayer and mpv branched off?). I found a more recent version in the mpv repo and it indeed has been addressed there:

typedef struct mp_image {
[...]
    uint8_t *planes[MP_MAX_PLANES];
[...]
} mp_image_t;

Now, I don't know if that is telling you to pull in mpv as a dependency, or if simply refactoring gimp-gap to pull in ffmpeg as a regular dependency and go from there. What fails to compile if you simply remove the "embedded" ffmpeg.tar.gz? Which API calls are being made? Perhaps it's as simple as pulling in ffmpeg.

ElMastro · 2025-02-08 02:07:04

First thing first, thank you @a821. Your suggestion is well appreciated.
Now, I believe mpv is a fork of mplayer, since I have both installed. However, I have to admit changing mp_image.h doesn't change anyhting, so I am wrong here, and this is undeniable.

From another point of view, removing

--with-ffmpegsrcdir="$PWD"/extern_libs/ffmpeg

from configure and updating libgapvidapi/gap_vid_api.c on line 1575 to

#include "libavformat/avformat.h"

makes the compilation arrive to this error

./libavcodec/x86/mathops.h: Assembler messages:
./libavcodec/x86/mathops.h:114: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:114: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:114: Error: operand type mismatch for `shr'
make[3]: *** [common.mak:32: libavformat/adtsenc.o] Error 1

that seems solvable. What do you think?

Arch Linux

#1 2025-01-12 22:56:03

gimp-gap PKGBUILD got a problem

#2 2025-01-13 00:27:14

Re: gimp-gap PKGBUILD got a problem

#3 2025-01-13 00:48:27

Re: gimp-gap PKGBUILD got a problem

#4 2025-01-14 00:01:45

Re: gimp-gap PKGBUILD got a problem

#5 2025-01-14 01:19:19

Re: gimp-gap PKGBUILD got a problem

#6 2025-01-14 10:40:31

Re: gimp-gap PKGBUILD got a problem

#7 2025-01-15 01:50:06

Re: gimp-gap PKGBUILD got a problem

#8 2025-01-15 04:01:01

Re: gimp-gap PKGBUILD got a problem

#9 2025-01-15 15:35:57

Re: gimp-gap PKGBUILD got a problem

#10 2025-01-16 01:32:51

Re: gimp-gap PKGBUILD got a problem

#11 2025-02-02 01:38:17

Re: gimp-gap PKGBUILD got a problem

#12 2025-02-02 20:28:54

Re: gimp-gap PKGBUILD got a problem

#13 2025-02-05 00:51:10

Re: gimp-gap PKGBUILD got a problem

#14 2025-02-05 08:11:34

Re: gimp-gap PKGBUILD got a problem

#15 2025-02-05 16:27:26

Re: gimp-gap PKGBUILD got a problem

#16 2025-02-06 02:06:06

Re: gimp-gap PKGBUILD got a problem

#17 2025-02-06 16:25:06

Re: gimp-gap PKGBUILD got a problem

#18 2025-02-06 23:06:05

Re: gimp-gap PKGBUILD got a problem

#19 2025-02-07 02:11:18

Re: gimp-gap PKGBUILD got a problem

#20 2025-02-08 02:07:04

Re: gimp-gap PKGBUILD got a problem

Board footer