XPaint / Bugs / #14 Build problem introduced in 2.9.10.1

Jean-Pierre Demailly - 2014-04-10

On Thu, Apr 10, 2014 at 05:32:22PM +0000, Stefan Husmann wrote:

[bugs:#14] Build problem introduced in 2.9.10.1

Status: open
Group: v1.0 (example)
Created: Thu Apr 10, 2014 05:32 PM UTC by Stefan Husmann
Last Updated: Thu Apr 10, 2014 05:32 PM UTC
Owner: nobody

Hello,

xpaint 2.9.10.1 introduces an error in a configure check.

Dear Stefan,

This is strange because I thought I hadn't changed anything to the configure
scripts. Also, It didn't realize the problem because I have been using for
my tests the "configure.old" script (which, for some reason that I don't
really understand seems to produce a not exactly equivalent and more reliable
binary file, in particular as far as mouse focus behavior is concerned).
I would tend to recommend using "configure.old" until this very minor
focus problem is fixed.

Anyway, to fix the problem with "configure", you have to modify the
configure.ac file by putting
[AC_LANG_PROGRAM([[#include <freetype2 config="" ftheader.h="">]])]</freetype2>,
instead of
[AC_LANG_PROGRAM([[#include <freetype config="" ftheader.h="">]])]</freetype>,
and running autoconf again. You may have to run "configure.old"
again once before running "configure" again. I'll definitely have
to fix these small issues for a more reliable build process ...

Thanks for the notice,

Jean-Pierre

Related

Bugs: #14

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Husmann - 2014-04-11

I should hav written that, but I made that change to the configure.ac file and the message remains the same. I also had to add an macro to it, that automake 1.14 needs. (patchfile attached)

Also running configure.old and confiure results in the same failing check for freetype headers.

I I run configure.old and make (without configure), running make fails with

gcc -O2 -fno-strength-reduce -fno-strict-aliasing -I/usr/include -Dlinux -Damd64 -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15 -DNARROWPROTO -DERRORBEEP -DFEATURE_FRACTAL -DXAWPLAIN -I/usr/include/X11 -I/usr/include/freetype2 "-DEDITOR=\"emacs -fn 9x15 -cr green -ms red -bg lightyellow -fg black\"" "-DSHAREDIR=\"/usr/share/xpaint\"" "-DXAPPLOADDIR=\"/usr/lib/X11/app-defaults\"" "-DXPAINT_VERSION=\"2.9.10.1\"" "-DLPCCMD=\"/usr/sbin/lpc status\"" -DERRORBEEP -DFEATURE_FRACTAL -c -o fileBrowser.o fileBrowser.c
In file included from xaw_incdir/ListP.h:41:0,
from fileBrowser.c:29:
/usr/include/X11/Xaw/SimpleP.h:69:5: error: unknown type name 'CoreClassPart'
CoreClassPart core_class;
^
/usr/include/X11/Xaw/SimpleP.h:92:5: error: unknown type name 'CorePart'
CorePart core;
^
In file included from fileBrowser.c:29:0:
xaw_incdir/ListP.h:55:5: error: unknown type name 'CoreClassPart'
CoreClassPart core_class;
^
xaw_incdir/ListP.h:110:5: error: unknown type name 'CorePart'
CorePart core;
^
<builtin>: recipe for target 'fileBrowser.o' failed
make: *** [fileBrowser.o] Error 1
==> FEHLER: Ein Fehler geschah in build().

autoconf.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Jean-Pierre Demailly - 2014-04-13
  
  On Fri, Apr 11, 2014 at 07:01:01PM +0000, Stefan Husmann wrote:
  
  I should hav written that, but I made that change to the configure.ac file and the message remains the same. I also had to add an macro to it, that automake 1.14 needs. (patchfile attached)
  
  Also running configure.old and confiure results in the same failing check for freetype headers.
  
  I I run configure.old and make (without configure), running make fails with
  
  gcc -O2 -fno-strength-reduce -fno-strict-aliasing -I/usr/include -Dlinux -Damd64 -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15 -DNARROWPROTO -DERRORBEEP -DFEATURE_FRACTAL -DXAWPLAIN -I/usr/include/X11 -I/usr/include/freetype2 "-DEDITOR=\"emacs -fn 9x15 -cr green -ms red -bg lightyellow -fg black\"" "-DSHAREDIR=\"/usr/share/xpaint\"" "-DXAPPLOADDIR=\"/usr/lib/X11/app-defaults\"" "-DXPAINT_VERSION=\"2.9.10.1\"" "-DLPCCMD=\"/usr/sbin/lpc status\"" -DERRORBEEP -DFEATURE_FRACTAL -c -o fileBrowser.o fileBrowser.c
  In file included from xaw_incdir/ListP.h:41:0,
  from fileBrowser.c:29:
  /usr/include/X11/Xaw/SimpleP.h:69:5: error: unknown type name 'CoreClassPart'
  CoreClassPart core_class;
  
  Dear Stefan,
  
  Your log indicates that you are compiling with plain Xaw, which is deprecated.
  The reason might be that 'configure.old' does not find the header
  files of Xaw3dxft where there are expected to be (/usr/include/X11/Xaw3dxft).
  Maybe libxaw3dxft-dev (or something like this) is missing.
  If Arch installs the headers elsewhere than where xpaint expects, a
  (very small) change in configure.old would be needed.
  
  Anyway, xpaint claims to be still compilable with plain Xaw -- this is
  indeed not so, as I didn't check that since a long time, and inadvertently
  made incompatible changes in between. This should be enough to explain
  your compilation troubles. I'll post a small patch to enable again
  compiling with libXaw (although I would strongly advise against that,
  the result is awful, all UTF8 input is badly displayed, etc ...)
  
  Best,
  Jean-Pierre
  
  PS. By the way, I didn't find a patch attached to your message !
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Husmann - 2014-04-15

Hello,

if I really did compile against libxaw, that was not intended. Arch Linux still has libxaw in its official repos, and I maintain libxaw3dxft and xpaint in the Arch User Repository (AUR). So for some other packages I have libxaw installed, and libxawxft3d in parallel.

autoconf.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Build problem introduced in 2.9.10.1

Group

Searches

Help

#14 Build problem introduced in 2.9.10.1

Related

Discussion

Related