Topic: GTK2 dependencies
started by: stupid_idiot
Posted by stupid_idiot on Jan. 05 2008,11:44Last 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:51Last edited on 13 Jan 2008.
List of dependencies:
Packages enclosed in "//" are 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:53Last edited on 13 Jan 2008.
List of dependencies (simplified):
Posted by Juanito on Jan. 05 2008,12:58Looking 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:16Hi 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.
-- 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:09Erm... 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.
Maybe we can configure libiconv like this??
('/usr/lib/libiconv.so.2*' already exists -- not needed)
'compile-<version>.uci' is a very nice name!!
Please keep up the good work!
Posted by Juanito on Jan. 05 2008,16:43
- 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:03If I'm not wrong, the libraries look like this:
1. 'configure' checks whether standard (Glibc's) iconv works.
2. If libiconv's 'iconv.h' is installed, 'configure' will probably fail with:
3. 'configure' will probably give this error:
-- Maybe set the LD_LIBRARY_PATH variable when compiling??
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!
Posted by ^thehatsrule^ on Jan. 05 2008,20:14Isn'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:22This 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
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:
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:
(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'):
Note: 'ldconfig' does not make use of LD_LIBRARY_PATH.
To test this, we could do the following, for example:
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'.
'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':
(1) Or, we can specify LDFLAGS when running 'configure':
< This TLDP page > has relevant information (look for "LD_LIBRARY_PATH").
Posted by stupid_idiot on Jan. 16 2008,09:07Rewrote the above post because it contained serious errors.
Very sorry for the misleading information!
The above post now has the correct information (hopefully!).