Hacking:Problems and solutions

From GIMP Developer Wiki
Revision as of 16:35, 3 January 2014 by Scl (Talk | contribs)

Jump to: navigation, search

This page describes problems that hamper the developers work and their solution. It's a knowledge base for developers. Feel free to add your own findings and don't be shy. It makes the work easier for all of us.


Building

BABL

Problem: Unit tests pass on one machine, but fail on another - equally configured - machine.

In this particular case the tests RGBA->HSLA and RGBA->HSVA passed on an amd64 platform, but failed on an i386 platform.

This is the content of file tests/testsuite.log on the i386 machine:

=======================================
babl 0.1.11: tests/test-suite.log
=======================================
# TOTAL: 19
# PASS:  17
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2
FAIL: hsl
=========
rgba to hsla  failed #0[0]  got 0.166667 expected 0.000000
rgba to hsla  failed #1[0]  got 0.666667 expected 0.000000
FAIL: hsva
=========
rgba to hsva  failed #0[0]  got 0.166667 expected 0.000000
rgba to hsva  failed #1[0]  got 0.166667 expected 0.000000


Cause: The tested code doesn't take into account that strict equality comparisons (==) will most often lead to different results on different platforms.

Solution: The code must take this fact into account. This means:

  • Don't use == for floating point comparisons!

The following lines show alternatives.

1. Make sure to have defined EPSILON first:

#define EPSILON 1.0e-10

2. Use EPSILON instead of == :

wrong right
if (value == 0.0) if (value < EPSILON)
if (value1 == value2) if (value1 - value2 < EPSILON) or

if (fabs (value1 - value2)) < EPSILON

See also Bugfix for RGBA->HSLA,HSVA conversions.

  • Make sure, your code works on all architectures. On a 64 bit machine this would mean also to compile and run make check with CFLAGS="-O2 -mfpmath=387".

If you're unsure, come to IRC (channels #gimp or #gegl) and ask.


GEGL

Problem: Building GEGL master stops with failing assertions related to GLib. The stopped build can't be aborted with Ctrl+C to enter new commands in that terminal session.

The following messages are shown at the screen:

CC       gegl-matrix.lo
CCLD     libgegl-0.3.la
GISCAN Gegl-0.3.gir
GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init()
GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE (interface_type)' failed
GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init()
GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init()
GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed


Cause: You have an old GLib version in your prefix. (Don't be fooled by just looking at the libglib version in your package manager!)

Solution:

  1. Close this terminal session and open a new one.
  2. Remove that old GLib version from your prefix and rebuild GEGL from scratch.


Problem: I have SPIRO (packages libspiro0, libspiro-dev) installed. However, at the end GEGLs configure step tells me, that no usable SPIRO was found.

GEGL builds and works anyway, because it is only an optional dependency.

Cause: The package of your distribution doesn't contain the link libspiro.so to the actual SPIRO library. On a Debian testing system this concerns the package libspiro0.

Solution: You have to set that link yourself. This bug is already known to the responsible Debian package managers.

On an i386 platform:

  1. cd /usr/lib/i386-linux-gnu
  2. Find out the actual libspiro file: ls -l libspiro.* The actual libspiro file is a plain file, not a symbolic link, and has a name similar to libspiro.so.0.0.1
  3. Set the link: sudo ln -s libspiro.so.0.0.1 libspiro.so. You will have to enter your password for this.
  4. Point your LDFLAGS variable to that directory: export LDFLAGS="${LDFLAGS} -L/usr/lib/i386-linux-gnu"
  5. Point your LD_LIBRARY_PATH variable to that directory: export LD_LIBRARY_PATH="/usr/lib/i386-linux-gnu:${LD_LIBRARY_PATH}"

If you're working on an AMD64 platform, replace i386-linux-gnu by x86_64-linux-gnu.


Problem: make install fails with error:cannot install ... to a directory not ending in ...

You get error messages like this

make[3]: Entering directory `/home/$your_username/build/gegl-master/operations/core'
/usr/bin/install -c -d /home/$your_username/gimp-install/gimp-feature2/lib/gegl-0.3
for i in clone.la convert-format.la crop.la nop.la; do \
	  /bin/bash ../../libtool --mode=install /usr/bin/install -c $i /home/$your_username/gimp-install/gimp-feature2/lib/gegl-0.3 ; \
	done
libtool: install: error: cannot install `clone.la' to a directory not ending in /home/$your_username/gimp-install/gimp-master/lib/gegl-0.3
libtool: install: error: cannot install `convert-format.la' to a directory not ending in /home/$your_username/gimp-install/gimp-master/lib/gegl-0.3
libtool: install: error: cannot install `crop.la' to a directory not ending in /home/$your_username/gimp-install/gimp-master/lib/gegl-0.3
libtool: install: error: cannot install `nop.la' to a directory not ending in /home/$your_username/gimp-install/gimp-master/lib/gegl-0.3
make[3]: *** [install-exec-local] Error 1
make[3]: Leaving directory `/home/$your_username/build/gegl-master/operations/core'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/$your_username/build/gegl-master/operations/core'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/$your_username/build/gegl-master/operations'
make: *** [install-recursive] Error 1

Cause: In a former step you've built GEGL into another prefix. Somehow the newer GEGL build reads remains of that in the aforementioned *.la files and stumbles over them.

Solution:

  1. Change into the build directory of that previous build (in the given example this is `/home/$your_username/build/gegl-master/operations/core), or into its root folder (here: /home/$your_username/build/gegl-master)
  2. Run make clean.
  3. Set your INSTALL_PREFIX variable properly to the folder where you want GEGL install in.
  4. Change into the folder where you build GEGL from (if you're not already there).
  5. Re-run configure --prefix=$INSTALL_PREFIX (or if you checked GEGL out from Git: autogen.sh --prefix=$INSTALL_PREFIX) && make && make install

GIMP

Problem: Building GIMP fails for instance in libgimpcolor with a message telling you, that some files in $ANOTHER_PREFIX/lib are missing and thus building libgimpcolor.la (or another *.la file) failed.

Cause: You switched over to another prefix. You already cleaned or removed that old prefix, but in your new prefix are some files referring to other files in that old prefix. In other words - there's an evil mixture of your new prefix and some old prefix zombies and libtool trips you up ;-)

Solution: Finding out the actually errorneous parts can take you hours, so it's better to make a clean sweep:

  1. Check your environment variables, especially the build environment variables. If they point to that old prefix, change them to point to the new prefix.
  2. Drop the contents of your new prefix.
  3. Rebuild from scratch. For BABL, GEGL and GIMP (and other libraries, if you use them):
    1. Change to their directory.
    2. Save your work (backup your working files or do git stash).
    3. Run git clean -xdf or drop the contents of the workspace except the .git folder or the source tarball.
    4. Run ./configure --prefix=$PREFIX (Git users: ./autogen.sh --prefix=$PREFIX).
    5. Run make && make install.

Some more information on building can be found at the building tutorials.


Problem: Building GIMP fails with a message, that the dependency gegl-0.2 > 0.2.0 is not met. But in $prefix I see the GEGL files, for instance gegl-0.3.pc in $prefix/lib/pkgconfig.

Cause: You have mismatched the versions:

GIMP 2.8 needs GEGL from the branch gegl-0-2.

GIMP 2.9 (=master) needs GEGL from the branch master.

Obviously you have mixed GIMP 2.8 with GEGL master.

Solution:

If you want to build GIMP 2.8:

  1. In GEGLs build directory run make uninstall.
  2. For GEGL checkout gegl-0-2, run make and make install.
  3. Go to the GIMP build directory and run configure/autogen.sh again, run make and make install.

If you want to build GIMP master:

  1. In GIMPs workspace run 'git checkout master'.
  2. Run configure/autogen.sh again, run make and make install.


Problem: GIMP build fails for missing BABL function

Example:

  /home/Workspace/gimp/app/core/libappcore.a(gimphistogram.o): In function `gimp_histogram_calculate':
  /home/Workspace/gimp/app/core/gimphistogram.c:261: undefined reference to `babl_format_get_model'
   operations/libappoperations.a(gimpoperationmaskcomponents.o): In function `gimp_operation_mask_components_prepare':
  /home/Workspace/gimp/app/operations/gimpoperationmaskcomponents.c:150: undefined reference to `babl_format_get_model'
  gegl/libappgegl.a(gimp-babl.o): In function `gimp_babl_format_get_base_type':
  /home/Workspace/gimp/app/gegl/gimp-babl.c:361: undefined reference to `babl_format_get_model'
  gegl/libappgegl.a(gimp-babl.o): In function `gimp_babl_format_get_linear':
  /home/Workspace/gimp/app/gegl/gimp-babl.c:454: undefined reference to `babl_format_get_model'
  gegl/libappgegl.a(gimp-babl-compat.o): In function `gimp_babl_format_get_image_type':
  /home/Workspace/gimp/app/gegl/gimp-babl-compat.c:38: undefined reference to `babl_format_get_model'
  collect2: error: ld returned 1 exit status

Cause:

You have an older version of babl installed on your system, either in your local installation prefix or by a package. In this case the package libbabl-dev 0.1.10-1 was installed. Although the build environment variables were set to rely on the local installation prefix, the linker checked this old version and failed for not finding the symbol `babl_format_get_model` in BABL.

Solution:

  1. Check the file $prefix/lib/pkgconfig/babl.pc. If you find a line with 'Version: 0.1.10' or older, then your BABL library is too old. In this case, goto step 2, otherwise to step 4.
  2. Change into your BABL source directory. Fetch the latest BABL source code, i.e. from git (branch 'master').
  3. Clean and rebuild BABL from scratch: run autogen.sh or config, make clean && make uninstall && make && make install
  4. In your package manager check the version of the BABL development library (on Debian systems: libbabl-dev, on Mandriva: libbabl-devel, on Red Hat systems:babl*src, on openSuSE systems:babl-devel). If you find version 0.1.10 or older, then your BABL library is too old. In your package manager remove it completely and also the GEGL development package depending on it.
  5. Also clean and rebuild GEGL from scratch to avoid version mismatch between GEGL and GIMP.
  6. Clean and rebuild GIMP from scratch.


Problem: Build of GIMP master fails in gimpcursor.c

Error messages:

/home/Workspace/gimp/app/widgets/gimpcursor.c:90:5: error: ‘cursor_corner_top’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:98:5: error: ‘cursor_corner_right’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:106:5: error: ‘cursor_corner_bottom’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:114:5: error: ‘cursor_corner_left’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:126:5: error: ‘cursor_side_top_right’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:134:5: error: ‘cursor_side_bottom_right’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:142:5: error: ‘cursor_side_bottom_left’ undeclared here (not in a function)
/home/Workspace/gimp/app/widgets/gimpcursor.c:150:5: error: ‘cursor_side_top_left’ undeclared here (not in a function)

Cause:

It's probably a gdk-pixbuf issue. It is for instance known to update the system loaders cache instead the cache of its local installation, if it's installed in a prefix which is in the PATH variable.

Workarounds:

Workaround A (the short tour):

  1. cd cursors
  2. make clean
  3. cd ..
  4. make


Workaround B (the big tour):

  1. gdk-pixbuf-query-loaders --update-cache (in case this doesnt work run it with sudo)
  2. add the Pkgconfigpath of libgdk-pixbuf2.0-dev to the PKG_CONFIG_PATH environment variable
  3. configure/autogen with your prefix
  4. make clean
  5. make


Anyway, these are just workarounds. If you know the cause and a proper solution, feel free to edit this article.


Problem: Errors on linking a static library, for instance with MinGW

Compiling GIMP fails, because of not finding a library which is actually there (for instance gexiv2).

The output of make V=1 produces a message like this:

*** Warning: This system can not link to static lib archive
/$your_workspace/share/crossroad/roads/w64/lib/libgexiv2.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

Cause:

You have not a shared (=dynamic) binary version, but a static binary of that particular library. Linking static binaries of most libraries is not supported by GIMP.

You can recognize this by the file file extensions:

Dynamic libraries have the extensions: so on Linux, dylib on OS X, dll on Windows.

Static libraries have the extensions: a on Linux and OS X, lib on Windows.


Solution:

1. Get a dynamic binary version of that library. Either the package manager of your distribution or the web holds one or you have to compile it yourself.

2. Compile GIMP again (starting with configure or autogen.sh to let the Autotools find the new library and make it included.)


Problem: Building GIMP fails with message ' Couldn't recognize the image file format for file ./cursor-bad.png'

The whole message is


Making all in cursors
make[2]: Entering directory `$your_workspace/gimp/cursors'
  GEN    tool-cursors.list
  GEN    gimp-tool-cursors.h

failed to load "./cursor-bad.png": Couldn't recognize the image file format for file './cursor-bad.png' 

Cause:

The environment variable XDG_DATA_DIRS is modified in your build environment, which confuses the GLib library (GDK-Pixbuf).


Solution:

  1. Don't modify the environment variable XDG_DATA_DIRS in your build environment. I.e. if you build from a build script, don't set this variable there.
  2. make distclean
  3. autogen.sh or configure
  4. make
  5. make install

Jenkins-specific

Problem: The compiler fails for a missing directory, although that directory exists

The file config.log contains the lines

configure:3796: checking whether the C compiler works
configure:3818: gcc ... "-L/usr/lib/x86_64-linux-gnu" ...  >&5
gcc: error: "-L: No such file or directory
gcc: error: /usr/lib/x86_64-linux-gnu": No such file or directory

Cause:

In Jenkins' global configuration you set the environment variable LDFLAGS="-L/usr/lib/x86_64-linux-gnu".

The quotes are not necessary here.

Solution:

Remove the quotes, save the global configuration and restart the job.

If the environment variable PKG_CONFIG_PATH also contains that directory, you can omit it in LDFLAGS.


Problem: Jenkins cannot access the Git repository

The console log contains the lines:

stderr: fatal: unable to connect to git.gnome.org:
git.gnome.org[...]: errno=Connection timed out

Cause:

The Gnome Git server is down for maintenance.

Solution:

Try again later.


Debugging

Git

Problem: After checking out a particular branch, Git tells me, that I'm a few commits behind,

for example: 'Your branch is behind 'origin/gimp-2-8' by 2 commits, and can be fast-forwarded.'

Cause: On git pull Git didn't update the HEAD on your local branch for whatever reason.

Solution: Try git pull origin to update your local branch.


Translating

Problem: I'm translating on the current production branch of GIMP (2-8 etc.) and on master. I'd like to cherry-pick my changes from the production branch to the master branch. But I get lots of merge conflicts and changes I never introduced.

Cause: Cherry-picking translations from the production branch into the master branch doesn't work.

Solution: Commit your translation updates directly into the master branch or try to merge your translation branch into the master branch.


Templates

Template for investigated solutions

Problem:

Cause:

Solution:

Template for workarounds

Problem:

Workaround:

Anyway, this is just a workaround. If you know the cause and a proper solution, feel free to edit this posting.