The Gimp 2.4


Forum: Apps
Topic: The Gimp 2.4
started by: meo

Posted by meo on Oct. 29 2007,16:52
Hello all app contributors to DSL!

I just saw that Gimp has come with it's sharp 2.4 version. Wouldn't it be nice to have an extension for DSL of that one. Unfortunately it's kind over my head to do one myself but if someone that has the skills is up to it I would be more than happy. Thanks beforehand!

Have fun guys,
meo

Posted by Juanito on Oct. 30 2007,05:34
I didn't look at the requirements for gimp-2.4, but it's a reasonable bet that many dsl libs will need to be upgraded and you will end up with a large (20MB+) extension - is this what you're looking for?
Posted by meo on Oct. 30 2007,06:04
Hi Juanito!

That would be perfect. To me size doesn't matter since I'm running DSL from a 8 GB CF card. So anything that works would be greatly appreciated!

As always have fun with DSL,
meo

Posted by Juanito on Oct. 30 2007,15:20
Excerpt from the gimp-2.4 install file:
Quote
1. You need to have installed a recent version of pkg-config available
    from < http://www.freedesktop.org/software/pkgconfig/. >  

 2. You need to have installed GTK+ version 2.10.13 or newer.  GIMP
    needs an even more recent version of GLib (>= 2.12.3).  It also
    wants Pango (>= 1.12.2).  Sources for these can be grabbed from
    < ftp://ftp.gtk.org/. >

 3. We require PangoFT2, a Pango backend that uses FreeType2. Make
    sure you have FreeType2 and fontconfig installed before you
    compile Pango.  FreeType2 can be downloaded from
    < http://www.freetype.org/. >  Fontconfig from
    < http://freedesktop.org/fontconfig/. >  GIMP depends on freetype2
    being newer than version 2.1.7 and fontconfig 2.2.0 or newer.
    Older versions are known to have bugs that seriously affect
    stability of GIMP.

 4. We use libart2. Grab the module libart_lgpl out of GNOME SVN or
    fetch the tarball from
    < ftp://ftp.gnome.org/pub/gnome/sources/libart_lgpl/ >

 5. We use dbus-glib if available. Grab it from
    < http://dbus.freedesktop.org/releases/dbus-glib/ >

 6. You may want to install other third party libraries or programs
    that are needed for some of the available plugins. We recommend
    to check that the following libraries are installed: libpng,
    libjpeg, libpoppler, libtiff, gtkhtml-2, libmng, librsvg, libwmf.

 7. The Python extension requires Python development headers to be
    present. You will also need PyGTK and the respective development
    headers.

- on the positive front, the compile extension I'm working on contains the latest version of pkgconfig...

Posted by meo on Nov. 26 2007,22:21
Well Juanito!

I checked up the requisits for Gimp 2.4.x and just realized that it was way over my head trying to do an extension of that. So I guess that's it!

have fun,
meo

Posted by Juanito on Nov. 27 2007,04:45
I don't think it would be that difficult, just very, very tedious.

You could start with pango-1.12.2, use "./configure --prefix=/opt/gimp-2.4 --enable-shared --disable-static"/ as a starting point, add anything needed from "./configure --help" and go for it.

I'd appreciate somebody testing the compile-3.3.5.uci extension :)

Posted by Juanito on Dec. 11 2007,11:48
I did look into this a little more and, yes, it was tedious...

So far I compiled freetype-2.1.8 -> fontconfig-2.2.0 -> glib-2.14.0 -> pango-1.12.2 -> atk-1.9.0

and now I'm stuck because the next steps are cairo-1.2.0 -> gtk+-2.10.13 and I cannot compile cairo. Even if I compile with --disable-xlib-xrender (or something like that), I get:
Code Sample
$ make
...
In file included from cairo-xlib-surface.c:40:
cairo-xlib-xrender.h:44:36: X11/extensions/Xrender.h: No such file or directory

It would seem to make sense that cairo is built so that it uses the xlibs in the base dsl rather than obliging a user to load xfree86 or xorg72. In addition, I doubt (but could easily be wrong) that including additional xlibs in an eventual extension would work well with the base dsl, so I don't know which way to go next.

Any ideas (as stated in another thread, cairo is used in several other applications that could be interesting on dsl)?

Posted by Juanito on Dec. 18 2007,09:31
OK, so I managed to compile cairo-1.2 but now I'm stuck compiling gimp-2.4 itself:
Code Sample
$ make
...
gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -o .libs/gimp-thumbnail-list gimp-thumbnail-list.o  ./.libs/libgimpthumb-2.0.so
/opt/gimp-2.4/lib/libgobject-2.0.so.0: undefined reference to `g_datalist_unset_flags'
/opt/gimp-2.4/lib/libgthread-2.0.so.0: undefined reference to `g_thread_gettime'
./.libs/libgimpthumb-2.0.so: undefined reference to `g_intern_static_string'/
etc, etc...

I've tried google on "undefined reference to `g_datalist_unset_flags'" and get 4 hits but I cannot access any of the sites - can anyone help out?

Note:
Code Sample
$ ldd /opt/gimp-2.4/lib/libgobject-2.0.so.0
       libglib-2.0.so.0 => /opt/gimp-2.4/lib/libglib-2.0.so.0 (0x40035000)
       libc.so.6 => /lib/libc.so.6 (0x400f7000)
       /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
-  I'm using glib-2.14 which should be sufficiently uptodate

Posted by john.martzouco on Dec. 18 2007,12:59
I get the same four hits.  you're right, the top two won't open.  But the Google 'Cached' link did for the first one and the last one.  The Cached links are underneath the main listing to the right of the URL shown in green.
Posted by WDef on Dec. 18 2007,13:25
Anything to do with 'undefined reference' is usually a missing/mismatched header for a lib.

I've tried getting into the google refs.  Contexts are not exactly the same.

Two suggest there is a problem with cairo or pango installs/versions.

Quote
al parecer hay problemas con las librerias de pango y cairo.... dijate si las instalaste bien, que version de UTUTO tenes instalada??


Another got this error building glib2 when using apgcc but not when compiling with gcc.  

Finally, German one:

Quote
`Ldd / usr/local/gnome-2.15.90/lib/libgobject-2.0.so` should provide information, which is probably wrong (an old) library glib up.


Dealing with prior errors suggested that linking was borked and asked if LD_LIBARY_PATH had been set.  One good idea from there was to do:

grep 'error' config.log
tail config.log

and look for errors.

Good luck.

EDIT:    g_datalist_unset_flags appears to be prototyped in glib.h

< http://developer.gimp.org/api/2.0/glib/glib-Keyed-Data-Lists.html >

EDIT2:  Also found this:

Quote

> g_thread_gettime should be defined in libglib-2.0.so.
> What is the output of
>
> $ nm libglib-2.0.so | grep g_thread_gettime
> $ nm libgthread-2.0.so | grep g_thread_gettime
> and
> $ ldd libgthread-2.0.so
> ?

Posted by meo on Jan. 02 2008,19:55
Hi guys!

How's the work with the new gimp extension getting along? I just saw that it's up in version 2.4.3 now. Hope all goes well because I'd love to use it with DSL and not having to change to another os to make some photo-work.

As always have fun,
meo

Posted by Juanito on Jan. 02 2008,20:32
...well, gimp starts to compile but then I run out of ram. I'll have to try again once I get back to my desktop and can symlink to hd.

Have you tried the image magik extension?

Posted by curaga on Jan. 03 2008,16:13
Running out of ram.. I have seen that too. Flite (a light speech synthetizer) takes more than 384mb, but it is compilable with 512mb.. I feel your pain bro!
Posted by stupid_idiot on Jan. 04 2008,07:52
Hi Juanito:
From this
Quote
/opt/gimp-2.4/lib/libgthread-2.0.so.0: undefined reference to `g_thread_gettime'
I guess your glib is installed in '/opt/gimp-2.4/lib/'?

I think the problem might be because 'libgthread-2.0.so.0' is still linked to DSL's glib at '/usr/lib/libglib-2.0.so.0'. (DSL's glib is version 2.6.4.)

Possible solutions:
-- Configure glib with "--prefix=/usr". This will overwrite the old '/usr/lib/libglib-2.0.so.0' with the new version.
-- Configure glib with "LDFLAGS='-Wl,-rpath,/opt/gimp-2.4/lib'". This way, 'libgthread-2.0.so.0' will look first in '/opt/gimp-2.4/lib/' for 'libglib-2.0.so.0'.

Posted by Juanito on Jan. 04 2008,12:39
I was thinking it must be something along those lines - I noticed that if I try to compile gimp immediately after compiling gtk, etc then I did not get this error. If I saved my progress to date as an extension and then came back to it then I get this error. I'll try to get back to this after a couple of days...
Posted by Juanito on Jan. 10 2008,11:03
Quote
I think the problem might be because 'libgthread-2.0.so.0' is still linked to DSL's glib at '/usr/lib/libglib-2.0.so.0

- you're right, when I remove /usr/lib/libglib-2.0.so.0 and replace it with a link to /opt/gimp-2.4 the error goes away.

Gimp also needed a newer version of libpng than that in dsl, the compile-3.3.5 MAX_PATH error needed fixing a couple of times and then, using a usb stick as additional memory, and after a loooong "make", it compiled.

...and it works  :)

Now comes the time to tidy up and think about the best way to format the extension. At present, I'm working with two extensions:

cairo-1.2.uci also containing the fontconfig, freetype & xorg72 libs required by cairo [2 MB]
gimp-2.4.uci also containing gtk-2 [40 MB]

I believe there are a couple of updated gtk-2 and/or cairo extensions in the making by stupid_idiot, maybe I should wait for these?

Posted by WDef on Jan. 11 2008,18:47
Quote
when I remove /usr/lib/libglib-2.0.so.0 and replace it with a link to /opt/gimp-2.4 the error goes away.


1. Need care with this approach with some builds - if the Makefile sets -rpath then the extension might keep looking for the newer glib in /usr/lib and not find it.  May not be a problem.

stupid_idiot's recommended approach of setting the -rpath one way or another so the library can be found in the uci is better.  I think you can do this in LDFLAGS if needed  with the syntax

LDFLAGS="-L/path/to/lib1 -L/path/to/lib2  -R/path/to/lib1:/path/to/lib2"

Suggest always setting LD_LIBRARY_PATH in the environment before the compile as well.

(NB the Germans agreed with stupid idiot - mismatched glib).

2. A request: perhaps consider leaving the headers in those uci extensions so we can compile other stuff against them rather than have to work out how to compile pango or something all over again?  Also build and include static libs as well as shared libaries so we can build static binaries against them if need be.

I can't think of the number of times I haven't bothered compiling something because it needs a newer glib than dsl's.

Thanks.

Posted by Juanito on Jan. 12 2008,05:46
Thanks for the suggestions.

Quote
Need care with this approach with some builds - if the Makefile sets -rpath then the extension might keep looking for the newer glib in /usr/lib and not find it.  May not be a problem.

- agreed, I did this just to see if I could compile gimp at all.

Quote
Suggest always setting LD_LIBRARY_PATH in the environment before the compile as well.

- after rebooting and leaving the base dsl libs in place, starting gimp from an icon with the command "LD_LIBRARY_PATH=/opt/gimp-2.4/lib:/opt/cairo-1.2/lib /opt/gimp-2.4/bin/gimp" seems to work fine.

Quote
perhaps consider leaving the headers in those uci extensions so we can compile other stuff against them

- it was my intention to do this with cairo as a minimum (but it could be done with gimp too) since several other apps seem to depend on cairo. So far I have the headers and the *la files but not the static libs, the extension would start to get seriously large® with these?

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.