GTK2 dependencies

Forum: Gtk2
Topic: GTK2 dependencies
started by: stupid_idiot

Posted by stupid_idiot on Jan. 05 2008,11:44

Last edited on 14 Jan 2008.
List of software (in alphabetical order):
(01) < GConf-2.2.1.tar.bz2 >
(02) < ORBit2-2.4.4.tar.bz2 >
(03) < atk-1.9.1.tar.bz2 >
(04) < bonobo-activation-1.0.4.tar.bz2 >
(05) < cairo-1.4.12.tar.gz >
(06) < gail-1.2.2.tar.bz2 >
(07) < glib-2.12.13.tar.bz2 >
(08) < gnome-icon-theme-2.8.0.tar.bz2 >
(09) < gnome-mime-data-2.2.1.tar.bz2 >
(10) < gnome-vfs-2.2.5.tar.bz2 >
(11) < goffice-0.2.2.tar.bz2 >
(12) < gtk+-2.10.14.tar.bz2 >
(13) < gtkhtml-3.1.20.tar.bz2 >
(14) < libIDL-0.8.9.tar.bz2 >
(15) < libart_lgpl-2.3.19.tar.bz2 >
(16) < libbonobo-2.0.1.tar.bz2 >
(17) < libbonoboui-2.2.5.tar.bz2 >
(18) < libcroco-0.6.1.tar.bz2 >
(19) < libglade-2.4.2.tar.bz2 >
(20) < libgnome-2.0.6.tar.bz2 >
(21) < libgnomecanvas-2.0.5.tar.bz2 >
(22) < libgnomeprint-2.8.2.tar.bz2 >
(23) < libgnomeprintui-2.8.2.tar.bz2 >
(24) < libgnomeui-2.2.2.tar.bz2 >
(25) < libgsf-1.14.7.tar.bz2 >
(26) < librsvg-2.16.1.tar.bz2 >
(27) < libxml2-2.6.31.tar.gz >
(28) < libxslt-1.1.22.tar.gz >
(29) < linc-1.0.3.tar.bz2 >
(30) < pango-1.16.5.tar.bz2 >
(31) < poppler-0.6.3.tar.gz >

Posted by stupid_idiot on Jan. 05 2008,11:51

Last edited on 13 Jan 2008.
List of dependencies:

Code Sample

1. cairo
1. glib
1. gnome-icon-theme
1. gnome-mime-data
1. libart_lgpl
1. libxml2

2. atk (*glib*)
2. libIDL (*glib*)
2. libcroco(*glib*,*libxml2*)
2. libxslt (*libxml2*)
2. linc (*glib*)
2. pango (*cairo*,*glib*)

3. ORBit2 (glib,*libIDL*,*linc*)
3. gtk+ (*atk*,cairo,glib,*pango*)

4. GConf (*ORBit2*,glib,linc,*gtk+*)
4. bonobo-activation (*ORBit2*,glib,linc)
4. libglade (atk,glib,*gtk+*,libxml2)
4. poppler (*//gtk+//*)

5. libbonobo (ORBit2,*bonobo-activation*,glib)
5. libgnomecanvas (gtk+,libart,*libglade*,pango)

6. gail (atk,gtk+,*libgnomecanvas*)
6. gnome-vfs (GConf,glib,gnome-mime-data,*libbonobo*,libxml2)
6. libgnomeprint (glib,libart,libxml2,*libbonobo*,pango)

7. libgnome (GConf,glib,*gnome-vfs*,libbonobo,libxml2)
7. libgnomeprintui (gnome-icon-theme,gtk+,libglade,libgnomecanvas,
*libgnomeprint*)
7. libgsf (glib,*//gnome-vfs//*,//libbonobo//)

8. libbonoboui (GConf,bonobo-activation,gtk+,libbonobo,libglade,*libgnome*,
libgnomecanvas)
8. librsvg (glib,//gtk+//,//libgnomeprint//,*//libgsf//*)

9. libgnomeui (GConf,*libbonoboui*,libglade,libgnome,libgnomecanvas)

10. goffice (gtk+,libart,libglade,libgnomeprint,*libgnomeui*)
10. gtkhtml (gail,gtk+,libglade,libgnomeprint,libgnomeprintui,*libgnomeui*)

Note:
Packages enclosed in "//" are optional dependencies.

Optional dependencies:
-- libgsf: //gnome-vfs// enables building of a wrapper for < GnomeVFS > [en.wikipedia.org].
-- libgsf: //libbonobo// enables building of a wrapper for < Bonobo > [developer.gnome.org].
-- librsvg: //gtk+// enables building of a SVG gdk-pixbuf loader (libgdk-pixbuf is the image loading/rendering library in GTK+).
-- librsvg: //libgnomeprint// enables printing support in librsvg.
-- librsvg: //libgsf// enables run-time decompression of compressed SVG images (*.svgz) in librsvg.
-- poppler: //gtk+// enables building of the poppler-glib wrapper (needed by GTK+ PDF apps that use poppler -- e.g. < Evince >).

Posted by stupid_idiot on Jan. 05 2008,11:53

Last edited on 13 Jan 2008.
List of dependencies (simplified):

Code Sample

Posted by Juanito on Jan. 05 2008,12:58

Looking at these listings, it would perhaps be smarter to try and compile gimp-2.4 to use this extension - to be sure I don't use the wrong extension(s) by mistake, which ones (including "dev" extensions) should I try to use?

Posted by stupid_idiot on Jan. 05 2008,14:16

Hi Juanito:
Apologies -- It has not been submitted yet. I think it will take about one more week (at least).
I think I will call the extension(s) 'gtk2.unc' and 'gtk2-dev.unc'.

Re: GIMP 2.4
Yes, I think GIMP 2.4 will be supported directly by this extension.
Small problem: This extension is built against GNU libiconv. But 'gcc1-with-libs.unc' uses Glibc's iconv, so I think you will get a link error ("undefined reference to 'libiconv_open'") when linking against the GTK2 libraries.

Possible solution:
-- Perhaps you can compile GNU libiconv as a .dsl and load it on top of 'gcc1-with-libs.unc'.
-- Or, maybe you can remaster 'gcc1-with-libs.unc'; I think you need to overwrite the original '/usr/include/iconv.h' with libiconv's 'iconv.h'; also you need to add '/usr/lib/libiconv.la'; lastly, '/usr/lib/libiconv.so.2' already exists in DSL -- but I think you will need to add a '/usr/lib/libiconv.so' symlink so that the linker can find
'-liconv' when linking.

I used libiconv version 1.9.2 (same as in DSL).
Link to source: < libiconv-1.9.2.tar.gz >

Posted by Juanito on Jan. 05 2008,15:19

...actually I was using compile-3.3.5.uci rather than gcc1-with-libs.unc

Since I didn't go fetch gnu libiconv, I guess compile-3.3.5 must be using the glibc version of libiconv - does it make sense to update compile-3.3.5 with this?

Posted by stupid_idiot on Jan. 05 2008,16:09

Erm... IMHO, GNU libiconv is a good drop-in replacement for Glibc's iconv. I mean, from my experience, I have not had any trouble compiling software using libiconv.

Re: 'compile-3.3.5.uci'
Maybe we can configure libiconv like this??

Code Sample

./configure \
--prefix=/opt/compile-3.3.5 \
--libdir=/usr/lib

-- 'iconv.h' will be installed at '/opt/compile-3.3.5/include/iconv.h'.

In 'user.tar.gz':
'/usr/lib/libiconv.la'
'/usr/lib/libiconv.so'
('/usr/lib/libiconv.so.2*' already exists -- not needed)

p.s.
'compile-<version>.uci' is a very nice name!!
Please keep up the good work!

Posted by Juanito on Jan. 05 2008,16:43

Quote

In 'user.tar.gz':
'/usr/lib/libiconv.la'
'/usr/lib/libiconv.so'
('/usr/lib/libiconv.so.2*' already exists -- not needed)

- What I've done until now is put a symlink to /lib or /usr/lib from /opt/compile-3.3.5/lib for the libs that exist in dsl and left the corresponding .la and .so in /opt/compile-3.3.5/lib. This seems to work and avoids having a large user.tar.gz

If this method is sound, I'll carry on in the same vein.

Posted by stupid_idiot on Jan. 05 2008,18:03

If I'm not wrong, the libraries look like this:
/opt/compile-3.3.5/lib/libiconv.so >>
/opt/compile-3.3.5/lib/libiconv.so.2 >>
/usr/lib/libiconv.so.2
and
/opt/compile-3.3.5/lib/libiconv.la

When configuring:
1. 'configure' checks whether standard (Glibc's) iconv works.
2. If libiconv's 'iconv.h' is installed, 'configure' will probably fail with:

Code Sample

undefined reference to 'libiconv_open'

2. If the first test fails, 'configure' checks for libiconv (looks for
'-liconv').
3. 'configure' will probably give this error:

Code Sample

/usr/bin/ld: cannot find -liconv

because '/opt/compile-3.3.5/lib/libiconv.so' is not in the default library path (defined in '/etc/ld.so.conf').

Possible solutions:
-- Maybe set the LD_LIBRARY_PATH variable when compiling??

Code Sample

export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib:/usr/local/lib:/opt/compile-3.3.5/lib

-- Or, run 'configure' with LDFLAGS??

Code Sample

LDFLAGS='-L/opt/compile-3.3.5/lib' \
./configure

I think my earlier suggestion to put '/usr/lib/libiconv.so' in 'user.tar.gz' was wrong because it is a waste of RAM.
You current method is correct; we just need to set LD_LIBRARY_PATH/LDFLAGS so that '-liconv' can be detected.
So, please continue with your current method!
Thanks!

Posted by ^thehatsrule^ on Jan. 05 2008,20:14

Isn't LD_LIBRARY_PATH only supposed to be used for finding dynamic/shared libraries during runtime?

Posted by stupid_idiot on Jan. 06 2008,03:22

This is how I understand LD_LIBRARY_PATH works:
Linking of programs during compilation is done by the linker ('ld').
Loading of shared libraries at runtime is done by the loader ('/lib/ld-linux.so.2').
Note: '/lib/ld-linux.so.2' is typically a symlink to
'/lib/ld-[glibc_version].so'.
e.g. '/lib/ld-linux.so.2' -> '/lib/ld-2.3.2.so' (DSL uses glibc 2.3.2.)
(1) For example: We have an application called 'my_program' that needs some libraries in '/opt/compile-3.3.5/lib/'.
We can add LD_LIBRARY_PATH to the environment, and then run the application:

Code Sample

export LD_LIBRARY_PATH=/opt/compile-3.3.5/lib
my_program

Or, we can add LD_LIBRARY_PATH to the command line; it will take effect only for this command; it does not persist in the environment:

Code Sample

LD_LIBRARY_PATH=/opt/compile-3.3.5/lib my_program

Code Sample

my_program LD_LIBRARY_PATH=/opt/compile-3.3.5/lib

(3) Another method, that does not involve LD_LIBRARY_PATH, is to add '/opt/compile-3.3.5/lib/' to the ld.so cache file ('/etc/ld.so.cache'):

Code Sample

# Edit /etc/ld.so.conf:
editor /etc/ld.so.conf
# Run 'ldconfig' to rebuild '/etc/ld.so.cache' using the directories specified in '/etc/ld.so.conf':
ldconfig
# Run application:
my_program

Note: 'ldconfig' does not make use of LD_LIBRARY_PATH.
To test this, we could do the following, for example:

Code Sample

export LD_LIBRARY_PATH=/opt/compile-3.3.5/lib
ldconfig
# Then unset LD_LIBRARY_PATH:
unset LD_LIBRARY_PATH
# Then run the application:
my_program
(You will get an error.)

As this shows, in line 2, 'ldconfig' does NOT add '/whatever/' to '/etc/ld.so.cache'.
Thus, once we unset LD_LIBRARY_PATH in line 4, the library in '/whatever/' can no longer be found.
Conclusion: The only way to add a directory to '/etc/ld.so.cache' is to edit '/etc/ld.so.conf'.

Re: Linking
'ld' can use LD_LIBRARY_PATH to find libraries at link-time (such as '-liconv') in the same fashion as above.
(1) We can export LD_LIBRARY_PATH before running 'configure':

Code Sample

export LD_LIBRARY_PATH=/opt/compile-3.3.5/lib
./configure
make

LD_LIBRARY_PATH must not be unset until compilation is finished; otherwise, linking errors will occur because the linker cannot find needed libraries.
(1) Or, we can specify LDFLAGS when running 'configure':

Code Sample

LDFLAGS=-L/opt/compile-3.3.5/lib ./configure

We don't need to use LD_LIBRARY_PATH if we use LDFLAGS (but I am not sure about this...).

< This TLDP page > has relevant information (look for "LD_LIBRARY_PATH").

Posted by stupid_idiot on Jan. 16 2008,09:07

Rewrote the above post because it contained serious errors.
Very sorry for the misleading information!
The above post now has the correct information (hopefully!).