1.3.0: build fails with gegl 0.4.16
kloczek opened this issue · 16 comments
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmypaint-1.3.0/gegl'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gegl-0.4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/json-glib-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/babl-0.1 -D_POSIX_C_SOURCE=200809L -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -c -o libmypaint_gegl_la-mypaint-gegl-surface.lo `test -f 'mypaint-gegl-surface.c' || echo './'`mypaint-gegl-surface.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gegl-0.4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/json-glib-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/babl-0.1 -D_POSIX_C_SOURCE=200809L -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -c mypaint-gegl-surface.c -fPIC -DPIC -o .libs/libmypaint_gegl_la-mypaint-gegl-surface.o
mypaint-gegl-surface.c: In function 'tile_request_start':
mypaint-gegl-surface.c:80:40: error: too few arguments to function 'gegl_buffer_iterator_new'
80 | GeglBufferIterator *iterator = gegl_buffer_iterator_new(self->buffer, &tile_bbox, 0, self->format,
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/gegl-0.4/gegl-buffer.h:758,
from /usr/include/gegl-0.4/gegl-types.h:96,
from /usr/include/gegl-0.4/gegl.h:28,
from mypaint-gegl-surface.h:20,
from mypaint-gegl-surface.c:22:
/usr/include/gegl-0.4/gegl-buffer-iterator.h:79:22: note: declared here
79 | GeglBufferIterator * gegl_buffer_iterator_new (
| ^~~~~~~~~~~~~~~~~~~~~~~~
mypaint-gegl-surface.c:91:52: error: 'GeglBufferIterator' {aka 'struct GeglBufferIterator'} has no member named 'data'
91 | request->buffer = (uint16_t *)(iterator->data[0]);
| ^~
make[2]: *** [Makefile:610: libmypaint_gegl_la-mypaint-gegl-surface.lo] Error 1
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmypaint-1.3.0/gegl'
make[2]: *** Waiting for unfinished jobs....
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmypaint-1.3.0/gegl'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gegl-0.4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/json-glib-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/babl-0.1 -D_POSIX_C_SOURCE=200809L -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -c -o ../glib/libmypaint_gegl_la-mypaint-gegl-glib.lo `test -f '../glib/mypaint-gegl-glib.c' || echo './'`../glib/mypaint-gegl-glib.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gegl-0.4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/json-glib-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/babl-0.1 -D_POSIX_C_SOURCE=200809L -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -c ../glib/mypaint-gegl-glib.c -fPIC -DPIC -o ../glib/.libs/libmypaint_gegl_la-mypaint-gegl-glib.o
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmypaint-1.3.0/gegl'
make[1]: *** [Makefile:855: all-recursive] Error 1
make: *** [Makefile:607: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.NrIjqC (%build)
from:
https://www.gimpusers.com/forums/gimp-developer/21248-libmypaint-needs-patching-for-recent-gegl
--- libmypaint-1.3.0-orig/gegl/mypaint-gegl-surface.c 2019-06-18 17:03:46.025060319 +0800
+++ libmypaint-1.3.0/gegl/mypaint-gegl-surface.c 2019-06-18 17:05:08.693421652 +0800
@@ -78,7 +78,7 @@
if (buffer_is_native(self)) {
GeglBufferIterator *iterator = gegl_buffer_iterator_new(self->buffer, &tile_bbox, 0, self->format,
- read_write_flags, GEGL_ABYSS_NONE);
+ read_write_flags, GEGL_ABYSS_NONE,100);
// Read out
gboolean completed = gegl_buffer_iterator_next(iterator);
@@ -88,7 +88,7 @@
g_critical("Unable to get tile aligned access to GeglBuffer");
request->buffer = NULL;
} else {
- request->buffer = (uint16_t *)(iterator->data[0]);
+ request->buffer = (uint16_t *)(iterator->items[0].data);
}
// So we can finish the iterator in tile_request_end()
It is pretty annoying, that GIMP 2.10.8 requires GEGL >= 0.4.12, but libmypaint 1.3.0 requires GEGL = 0.3. That means, I need two instances of GEGL on my system.
@spixi Note that the GEGL dependency is not a requirement at all. It's fully optional. As far as I know, it is needed nowhere, neither in MyPaint nor in GIMP. I'm not really sure which software actually use libmypaint-gegl. So unless you need it yourself, you probably don't actually need 2 instances of GEGL on your system. :-)
@Jehan: Thank you for Here are some projects, which use the MyPaintGegl API:
https://github.com/search?q=MyPaintGegl&type=Code
Backlink to Gentoo Bugzilla: https://bugs.gentoo.org/690352
@Jehan: Thank you for Here are some projects, which use the MyPaintGegl API:
https://github.com/search?q=MyPaintGegl&type=Code
I can only see a single instance of "possible" actual use in that list, and that was an experimental fork that has been inactive for 5 years. The rest are just instances of the same example file, and the same patch to libmypaint updating the unused dependency.
@jplloyd: I see. Dopey looks like an abandoned fork of MyPaint. So, do you consider, the GEGL port is completely obsolete? Which consequences would removing the MyPaintGeglTiledSurface at all have?
@spixi Dopey only has a copy of example files from before the brushlib -> libmypaint transition, the only legitimate use is https://github.com/manuq/xsheet, which has not been updated in 4½ years.
Can't say with certainty, but I don't think removing it would impact any active project.
MyPaintGeglTiledSurface is just a wrapper for mypaint_tiled_surface*. It would be possible to make a separate library, if something requires that.
Note that I was not advocating at all that mypaint-gegl should be removed, though I'm not entirely sure what it does. I was just saying that so far I haven't seen big usage of it.
But unless it actually became a liability to the rest of the program, I don't think it should be removed. It's still the result of some people's hard work which may be useful to some other people. :-)
Note that I was not advocating at all that mypaint-gegl should be removed, though I'm not entirely sure what it does. I was just saying that so far I haven't seen big usage of it.
But unless it actually became a liability to the rest of the program, I don't think it should be removed. It's still the result of some people's hard work which may be useful to some other people. :-)
I agree with this sentiment. Solution seems to be to have separate distributions of libmypaint and libmypaint-gegl. Btw, is the cause of this problem a case of packagers deliberately enabling gegl in distribution builds, seeing as it's disabled by default?
Hi, I just started a new experimental project to use gegl and mypaint.
I hope gegl support will be kept in the future.
@seagetch The only thing, what the GEGL support adds, is the MyPaintGeglTiledSurface object, which is useful for standalone applications solely based on LibMyPaint. LibMyPaint itself does not make actual use of GEGL. GIMP uses GEGL, but does not require LibMyPaint with GEGL support. I think the whole thing leads to confusing misconceptions.
Yes, I've started new standalone application based on libmypaint and gegl.
libmypaint support is under testing, so no code available on he repository. Anyway, I tested libmypaint with MyPaintGeglTiledSurface.