Package Details: exact-image 1.0.2-1

Git Clone URL: https://aur.archlinux.org/exact-image.git (read-only)
Package Base: exact-image
Description: Fast image manipulation programs
Upstream URL: http://exactcode.com/opensource/exactimage/
Licenses: GPL2
Submitter: lisu_ml
Maintainer: haawda
Last Packager: haawda
Votes: 6
Popularity: 0.005326
First Submitted: 2016-08-29 16:04
Last Updated: 2019-01-29 21:33

Pinned Comments

jmb commented on 2018-04-04 12:50

@haawda The Evas_Engine_Software_X11.h issue happens only if you have efl installed. Evas_Engine_Software_X11.h was an internal elf header that applications should not use and that has been removed in recent efl releases. If efl is not present, exact-image does not try to build edisplay and the error does not occur.

Latest Comments

1 2 Next › Last »

jmb commented on 2018-04-04 12:50

@haawda The Evas_Engine_Software_X11.h issue happens only if you have efl installed. Evas_Engine_Software_X11.h was an internal elf header that applications should not use and that has been removed in recent efl releases. If efl is not present, exact-image does not try to build edisplay and the error does not occur.

haawda commented on 2018-02-03 19:33

Cannot reproduce, builds fine here.

seifferth commented on 2018-01-27 23:22

I seem to be getting the same error andybutterworth described. Does anyone here have any idea as to why? Was the issue resolved somehow?

Error Message:

In file included from gfx/X11Helper.cc:36:0:
gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory
 #include "Evas_Engine_Software_X11.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

haawda commented on 2017-11-08 18:47

Maybe it builds for me because I have no php here. Can you please try if adding "--without-php" to the configure-options makes it buildable?

AnySomebody commented on 2017-11-08 12:37

Does not build for me:

In file included from /usr/include/php/Zend/zend.h:33:0,
from objdir/api/php/api-php-wrap.cc:748:
objdir/api/php/api-php-wrap.cc: En la función ‘void _swig_default_rsrc_destroy(zend_resource*)’:
objdir/api/php/api-php-wrap.cc:6489:9: error: ‘rsrc’ no se declaró en este ámbito
efree(rsrc->ptr);
^
/usr/include/php/Zend/zend_alloc.h:163:34: nota: en definición de macro ‘efree’
#define efree(ptr) _efree((ptr) ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC)
^~~
make: *** [build/bottom.make:76: objdir/api/php/ExactImage.so] Error 1

andybutterworth commented on 2017-09-21 18:43

Build fails

In file included from gfx/X11Helper.cc:36:0:
gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory
#include "Evas_Engine_Software_X11.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [build/bottom.make:58: objdir/gfx/X11Helper.o] Error 1
rm objdir/frontends/bardecode.o objdir/frontends/econvert.o objdir/frontends/edentify.o objdir/frontends/hocr2pdf.o objdir/frontends/e2mtiff.o objdir/frontends/empty-page.o objdir/frontends/optimize2bw.o
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build exact-image.

kashif commented on 2017-08-09 15:33

Builds now, great job!

lisu_ml commented on 2017-08-08 22:15

Thanks, @kashif.

I had no elf installed, so the issue was not triggered on my machine. After installing it I experienced the issue reported by you. After quick look I decided to use patch that I found in Debian repositories.

Please let me know if the issue is now resolved on your end.

kashif commented on 2017-08-08 21:19

Hi lisu_ml,

Thanks for the quick response! The update with exact-image-types.patch did not help with the compilation issue.

The problem seems to be that both Evas and Evas_Object have the same underlying type, namely Eo, as provided by the current version of efl (1.18.4-3).

From /usr/include/evas-1/Evas_Common.h:

typedef Eo Evas;
...
typedef Eo Efl_Canvas_Object;
typedef Efl_Canvas_Object Evas_Object;

The compiler is upset that X11Window::CaptureIntoEvasImage(..) is overloaded with two parameter lists that are identical, and have Eo* as the first parameter.

It's curious that you aren't able to reproduce the issue. Perhaps your Evas_Common.h is provided by a different package? Maybe you have an outdated version of efl? Perhaps different gcc flags?

$ pacman -Qo /usr/include/evas-1/Evas_Common.h
/usr/include/evas-1/Evas_Common.h is owned by efl 1.18.4-3

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.1 20170630 (GCC)

lisu_ml commented on 2017-08-08 16:54

Hey @kashif, thanks for reporting the problem.

Though I cannot reproduce it on my machine (Current Arch, gcc 7.1.1 20170630), I created the patch, that may make things work for you.

It is already committed and pushed, so could you please try rebuilding the package and let me know if your issue is solved?

Thank you.