+++ This bug was initially created as a clone of Bug #270647 +++ current media-libs/gegl stable results in this failure with USE="doc": cp index-static.txt index.html /usr/bin/asciidoc --unsafe -o index.html -a stylesdir=`pwd` -a toc -a theme=gegl -a quirks! index-static.txt ** Message: Module '../operations/workshop/external/.libs/ff_save.so' load error: ../operations/workshop/external/.libs/ff_save.so: undefined symbol: sws_scale ** Message: Module '../operations/workshop/external/.libs/ff_save.so' load error: ../operations/workshop/external/.libs/ff_save.so: undefined symbol: sws_scale make[3]: *** [operations.html] Erreur 255
I have the same problem. I will attach my build log file.
Created attachment 225275 [details] Build log file
# emerge -pqv =media-libs/gegl-0.0.22 [ebuild N ] media-libs/gegl-0.0.22 USE="cairo doc ffmpeg jpeg mmx png raw sdl sse svg -debug -openexr -v4l"
Reproduced
Same problem here
Same problem
same here, reemerged with -doc fine
Created attachment 237987 [details] A build log showing some errors, but still completing without failure. For me merging gegl with USE=doc did NOT fail. But I still see many of the same sws_scale symbol errors in my build log (attached). It seems that some of the problems are ignored (does not cause the build to fail). The command that caused Pierre's build to fail did not produce any errors in my case, and thus did not stop the build. However, after the merging, when I start gimp, I get a very similar error message as seen in the build logs: ** Message: Module '/usr/lib64/gegl-0.0/ff_save.so' load error: /usr/lib64/gegl-0.0/ff_save.so: undefined symbol: sws_scale Gimp appears to work normally despite this error, I guess I just didn't happen to need the feature. I was able to create images and save PNG files just fine. As a side note, revdep-rebuild did not report that anything needed rebuilding.
This is a bug with the patch applied from bug #270647, you need to call eautoreconf after applying the patch since you modify a Makefile.am.. I was going to commit the fix, but it seems out dear CVS server isn't responding to me. Actually, there is also a second bug here, the doc generation crashes with: babl-memory.c:86 functions_sanity() babl memory function(s) attempted switched on the fly [Thread debugging using libthread_db enabled] 0x00007fc3ec8b934e in __libc_waitpid (pid=<value optimized out>, stat_loc=0x7fff62c4ff8c, options=<value optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:32 32 return INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL); #0 0x00007fc3ec8b934e in __libc_waitpid (pid=<value optimized out>, stat_loc=0x7fff62c4ff8c, options=<value optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:32 #1 0x00007fc3ec854a89 in do_system (line=<value optimized out>) at ../sysdeps/posix/system.c:149 #2 0x00007fc3ecdfed78 in babl_backtrack () at babl-internal.c:67 #3 0x00007fc3ecdfed99 in babl_die () at babl-internal.c:73 #4 0x00007fc3ecdffc50 in babl_free (ptr=0x61ad80) at babl-memory.c:194 #5 0x00007fc3ecdf9e67 in each_babl_extension_destroy (babl=0x61ad80, data=0x7fff62c4ff8c) at babl-extension.c:356 #6 0x00007fc3ece02369 in babl_list_each (list=0x61a910, each_fun=0x7fc3ecdf9e40 <each_babl_extension_destroy>, user_data=0x0) at babl-list.c:152 #7 0x00007fc3ecdf9e09 in babl_extension_destroy () at babl-extension.c:360 #8 0x00007fc3ecdf7d69 in babl_destroy () at babl.c:65 #9 0x00007fc3ee719bac in gegl_exit () at gegl-init.c:337 #10 0x00000000004018c3 in main (argc=2, argv=0x7fff62c50428) at operation_reference.c:360 Maybe we just want to push 0.1.6 to stable ? or does it break the api/abi ?
Due to serious issues with the doc useflag it was dropped thus closing this bug as fixed. If somebody is interested in doc features they need to open feature request with relyable working approach for them. (gegl-0.1.6 is stable candidate and does not have the doc useflag)
