![[Way qool image]](http://www.rru.com/Images/blackhole2.gif)
Just the FAQs, please!
Last updated: Thursday, 04-Apr-2002 13:18:59 CST
A number of questions related to pre-1,0 releases have been removed. You should really upgrade to the latest release if at all possible. 1.0 is far more stable than any of the developer releases! If you really need an answer to a pre-1.0 question, email the FAQ maintainer at meo@rru.com . If it was in the FAQ, I'll mail it to you.
| Y2K | General | Plug-Ins | GTK+ | Script-Fu | Platforms |
|---|
If your question isn't here, it might be more of a User FAQ than a developer FAQ. Look there before you panic.
The latest version of this FAQ should always be available at http://www.rru.com/~meo/gimp/faq-dev.html .
You may submit material to the maintainer, Miles O'Neal, at meo@rru.com .
Quote of the Something
...birds don't make nifty pencil-tips for sketching...
-Jim Harmon (12 Mar 1998, gimp-developer mailing list)
The first production release is out - 1.0.0 !
Yes. To produce a much smaller GIMP, do the following:
rm config.cache
LDFLAGS="-s" ; export LDFLAGS # for csh use setenv LDFLAGS "-s"
./configure --disable-debug
make
Then, if you run into problems...
rm config.cache
LDFLAGS="" ; export LDFLAGS # for csh use unsetenv LDFLAGS
./configure --enable-debug
make # for just the libraries and executables needing debugging
You may need to use gmake (GNU's make). It's available wherever GNU utilities are available, such as ftp.sunsite.edu .
Two reasons. First, in a word, ``bloat''. Instead of one reasonably-sized program plus whatever plug-ins happened to be running at the moment, you would have one humongous program.
The other problem is ownership. Right now, anyone can write a plug-in, maintain it, fix it, enhance it, etc, and it has no effect on anything else in the gimp, or on any other developers. If everything moved into one package, the whole multi-developer paradigm would quickly bog down in detail, and ultimately, one person would end up holding the bag.
There are two shared memory issues - operating system shared memory and X shared memory.
There are lots of GIMP pages out there now, but these are the primary starting points for developers, at this time. Much of what used to be listed separately here has been moved to one of the links off the GIMP's home page.
See the Gimp Documentation pages at http://www.gimp.org/ .
There are other gimp-related lists there as well.
I'm not sure who maintains these any more, but the latest list I was provided contains the follownig:
| Hostname | Port | Location |
|---|---|---|
| irc.gimp.org | 6667 | dynamic |
| irc.au.gimp.org | 6667 | Australia |
| irc.su.gimp.org | 6667 | USA |
| irc.acc.umu.se | 6667 | Sweden |
``All the excitement is in channel #GIMP.'' -Zach
It's under development. For more information, see Owen Taylor's <otaylor@gtk.org> page about XInput support for GTK and the GIMP.
There is some support, but you have to do a little extra work to compile it in.
See http://www.levien.com/free/linux_intuos.html by Terry Mackintosh, or http://www.gtk.org/~otaylor/xinput/ for details, but here's the quick overview from Juergen Schlag <j.schlag@callisto.fulda.net>:
Yes. You can run xscanimage, the front end to SANE (Scanner Access Now Easy), either as a GIMP extension or in stand-alone mode. This supports Mustek and HP flatbed scanners, as well as the Connectix color QuickCam camera.
Further information is available at http://www.mostang.com/sane/ .
| tiff | ftp://ftp.sgi.com/graphics/tiff/ | (v3.4 works) | compressed (.Z) | gzipped (.gz) |
|---|---|---|---|---|
| jpeg | ftp://ftp.uu.net/graphics/jpeg/ | (6a works) | gzipped (.gz) |
You can get libmpeg from ftp.gimp.org/pub/gimp/libs/mpeg_lib-1.2.2adm.tar.gz .
The first method below works for most people, but if not, look at the second one.
Method 1
Assuming you have the correct versions of the JPEG and TIFF libraries (see below) built on your system, edit the plug-ins/Makefile to add the following lines after the INCLUDES = \ line:
-I/usr/local/include/jpeg \
-I/usr/local/include/tiff \
and modify the jpeg_LDADD and tiff_LDADD lines
to include -L options as follows:
jpeg_LDADD = $(pre_LDADD) $(x_LDADD) -L/usr/local/lib -ljpeg $(post_LDADD) tiff_LDADD = $(pre_LDADD) $(x_LDADD) -L/usr/local/lib -ltiff $(post_LDADD), obviously using the correct pathnames for your installation.
If you still have problems, run the following command:
find / -name libjpeg\* -print
and see if you have other JPEG libraries (or substitute libtiff
if you are having TIFF troubles). If you find other versions,
remove, rename, or hide them temporarily and try compiling again/
Method 2
Add the following lines to plug-ins/jpeg/Makefile in the INCLUDES = \ line:
-I/usr/local/include/jpeg \
and in the LDADD = \ line:
-L/usr/local/lib -ljpeg \
You either don't have the XPM package installed, or you have the wrong version of XPM installed, or it's in a non-standard place. Check the GIMP install document to see which version you need; then make sure the include files and library are in paths defined in the Makefile (usually /usr/{lib,include}/X11 or /usr/local/{lib,include}).
If they are elsewhere, modify the Makefile appropriately.
You can get libxdelta from ftp.gimp.org/pub/gimp/libs/xdelta-0.20.tar.gz .
Both users and developers can find a HOWTO report GIMP bugs at http://carol.gimp.org/gimp/howtos/bugzilla/bugzilla2.html for the time being (it should be integrated in the new www.gimp.org later on).
Depends on what you find. If they seem to be plug-in problems, you definitely want to try to tell the plug-in authors (look in the offending plug-in's source or on the Plug-in Registry web page).
For core functionality, you can report them at http://bugzilla.gnome.org.
Finally, if you need to discuss it with a wider developer audience (perhaps because it is really a feature request instead of a bug), send email to the GIMP developer mailing list. It's a good idea to say something like "[bug]" or [patch]" in the subject where applicable.
Always include the system type, OS, window manager, X version, etc, as well as the GIMP version (and GTK version if known), and anything else that might be applicable.
It's OK to send related problems in a single email.
Of course, patches are always welcome. 8^)
Yes, it's under CVS, and there is anonymous access.
See http://www.gimp.org/devel_cvs.html for details.
Ingo Luetkebohle <ingo@blank.pages.de> has developed an automated registry for plug-ins...
Browse a complete selection of plug-ins, with easy downloading,
automated submission of new plug-ins and lots more to come at:
http://registry.gimp.org/
You should also announce it on the gimp-developers and/or
gimp-users mailing lists.
The easiest way is to find a similar plug-in and modify it. If you don't see all the features you want in one, take parts from several. It's best to start simply, and add features. This has several advantages - you are concentrating on one thing at a time so you can do a better job, you will only have to debug one thing at a time (a BIG win), and you will probably learn each piece more thoroughly. (If you look at the available plug-ins, you will see that most of them branched from just a few originals.) This is actually a good way to learn almost any new language, library, system, etc. There's an annotated plug-in sample at http://www.rru.com/~meo/gimp/rand-noted.c for this purpose, but it's rather out of date.
Also, Kevin Turner has a tutorial on plug-in writing at http://gimp-plug-ins.sourceforge.net/doc/Writing/html/plug-in.html .
Each entry has three elements: the type, a name string, and a definition string. Both string values are user-definable. The first element must be one of the types defined in the GParamType enumerated type in libgimp/gimpenums.h .
The first three entries in the GParamDef array must be of the correct types, in order: PARAM_INT32, PARAM_IMAGE, and PARAM_DRAWABLE. You need all three of these, and might as well just copy them verbatim from an existing plug-in.
In the words of Quartic (Federico Mena):
``The PARAM_IMAGE parameter refers to the image the plug-in was invoked from. Most plug-ins do not make use of that parameter, since they only care about getting a drawable to operate on (the third parameter).
``If you want to write a plug-in for RGB images only, then you should specify one of the "RGB", "RGBA", "RGB*" strings when calling gimp_install_procedure() in your query_proc. That is where the GIMP knows what types of images the plug-in can accept.''
Again in the words of Quartic (Federico Mena):
``Run_modes tell the plug-in whether it is being called interactively (i.e. the user selected it from an image's pop-up menu) or non-interactively (from a script, for example). If a plug-in is called interactively, it should display its dialog box if it has one. If it is called non-interactively, it should not display any kind of user interface; instead it should use the parameters it is passed.''
The three definitions for the run modes are RUN_INTERACTIVE, RUN_NONINTERACTIVE, and RUN_WITH_LAST_VALS. Again, if you base your plug-in on an existing one, you'll see clues to where you need to worry about the modes by looking for these. You might want to look at a complex plug-in as well as a simple one to make sure you have all the bases covered.
Some of the plug-ins have proven unstable. These have been moved into a separate download, which should be available wherever you got the GIMP, in the file gimp-plugins-unstable-VERSION.tar.gz or gimp-plugins-unstable-VERSION.tar.bz2 .
Since this list can change frequently, it is not included here.
If you had a really early developer version (such as 0.54), the plug-in interface changed completely, and some of the plug-ins may not have been ported. If this is the case, feel free to port it yourself, but check the Plug-in Registry first, because someone else may have recently ported the plug-in you're after.
You can use GDK_DISPLAY() for that.
It's a GUI API. It was written for the GIMP, to get rid of its dependency on Motif. It officially stands for the GIMP ToolKit, although the G may eventually mean General or GUI or GNU or something as it gets used more outside the GIMP, in things like the gzilla browser.
Shawn T. Amundson started the GTK documentation web pages, which have migrated to http://www.gimp.org/gtk/ .
Box packing refers to how your controls are laid out in an hbox or vbox. Raph Levien has written a tutorial on box packing.
Thanks again to Quartic:
At the start of your callback function:
if (!GTK_TOGGLE_BUTTON(button)->active)
return; /* or whatever you want to do */
If you are seeing complaints about the wrong number of arguments for some gtk function[s], and/or an unresolved reference to some gtk function[s], you need a newer version of GTK. Get it at
ftp://ftp.gimp.org/pub/gtk/ .After you build it, remove any old versions (or move them elsewhere) and install the new version. The GIMP build process insists on using the installed gtk+ libraries at this time.
In the words of S&P:
Script-Fu is the first GIMP scripting extension. Extensions are separate processes that communicate with the GIMP in the same way that plug-ins do. The distinction is that extensions don't require an active image to operate on, instead extending the GIMP's functionality. GIMP internals for version 1.0 have been completely overhauled from version 0.54. In particular, the plug-in API has been made far more general with the advent of the procedural database (PDB). The PDB allows the GIMP and its plug-ins to register procedures which can then be called from anywhere: internally, from extensions, and from plug-ins. There are already over 200 internal GIMP procedures, and more being created all the time. Because all of these procedures can be easily invoked from extensions, the logical next step was to create a scripting facility; thus, Script-Fu was born.
As with plug-ins, web pages, COBOL, or anything else, one of the best things you can do is look at other peoples' code, and play with it. But it helps a lot if you know Scheme.
The trick to calling script-fu-scripts from another script is to just reference the main define for the script and not to try to use the pdb call. All the scripts in script-fu share a common name space; you call other scripts just like a regular function / define / whatever you call those those things in_scheme.
Ie, to call script-fu-predator in a script, just use
(script-fu-predator img drawable 2 TRUE 3 TRUE TRUE)
For examples, see
http://www.gimp.org/~adrian/scripts/test.scm .
From the script-fu console, call a plug-in like this:
(plug-in-name 1 0 0 100.0 1.0 10 0)The first parameter should always be a "1". The next two are the image number and drawable. Anything following these numbers will be plug-in parameters, which depend on the plug-in.
Inside an actual script, call a plug-in like this:
(define (script-fu-fred img drawable)
(plug-in-randomize-hurl 1 img drawable 100.0 1.0 10 0)
(gimp-displays-flush)
)
(script-fu-register "script-fu-fred"
"<Image>/Script-Fu/fred"
"Randomize test"
"Miles O'Neal <meo@rru.com>"
"Miles O'Neal"
"1998/May/1"
"RGB*, GRAY*, INDEXED*"
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0)
Invoke the script as non-interactive and add a pair of escaped quotes around each string just like you do in (script-fu-register). You DO NOT need to replace '-' with '_' in any names or registrations.
Example script:
(define (script-fu-famhist-link text filename)
;; code ommitted for brevity
(file-gif-save 1 img 0 filename "" FALSE FALSE 0 0))
(script-fu-register "script-fu-famhist-link"
"<Toolbox>/Xtns/Script-Fu/Family Historian/Link"
"Family Historian Link"
"John Johnson"
"John Johnson"
"1998"
""
SF-VALUE "Text String" "\"Family Historian\""
SF-VALUE "Base filename" "\"foo\""
)
Example Invocation:
;; note the '1' as the first argument tell it to run non-interactivly
;; note the \" \" pairs around the strings
gimp -n -b '(script-fu-famhist-link 1 "\"Introduction\"" \
"\"intro.gif\"")' '(gimp-quit 0)'
For a detailed, step by step explanation, check out Adrian's
Gimp Batch Mode how-to at
http://adrian.gimp.org/batch/ .
Dov Grobgeld wrote a tutorial specifically to get Script-Fu users up to speed quickly. It's available at http://imagic.weizmann.ac.il/~dov/gimp/scheme-tut.html . Thanks to Henk Huitema (huitema@cwi.nl) for passing on this URL after the original pages disappeared. You might also check out MIT's Scheme page.
Tim Mooney asked about scheme documentation on the developer's mailing list; here is his summary:
Regarding my query on good references for a would-be
Schemer, thanks to:
"Daniel X. Pape" <dpape@ncsa.uiuc.edu>
Quartic (federico@nuclecu.unam.mx)
Erik Nygren <nygren@mit.edu>
Andy Thomas <alt@picnic.demon.co.uk>
Quartic and Erik indicated that the canonical reference
for Scheme is:
Abelson, H., G. Sussman and J. Sussman
"Structure and Interpretation of Computer Programs"
MIT Press, 2nd ed.
August 1996
ISBN 0-262-01153-0
657 pp.
$60.00 (cloth)
There is a web page companion for the book at:
http://www-mitpress.mit.edu/sicp/
Daniel suggested I just do a net search and provided me
with a good starting point at Yahoo:
http://www.yahoo.com/Computers_and_Internet/Programming_Languages
Andy pointed a SIOD reference at delphi,
but that appears to have disappeared
since we first listed it here. Branko
Collin found a copy at:
http://www.cs.indiana.edu/scheme-repository/imp/siod.html .
While doing some searching with HotBot for the book Quartic
and Erik mentioned, I found another possibly useful site:
http://www.schemers.com/products.html
Also, check out Mark Galassi's documentation page, at:
http://nis-www.lanl.gov/~rosalia/mydocs/
Mark is the primary maintainer for Guile, the GNU Scheme
extension language.
Giacomo Boffi offered an alternative viewpoint:
Structure and Interpretation of Computer Programs is invaluable as a learning tool for computer science. on the contrary, its usefulness wrt learning scheme, taking into account the limited aims that prompt most fu-scripters, could be questioned i'd like to point to another book by MIT PRESS, The Little Schemer - 4th Edition by Daniel P. Friedman and Matthias Felleisen drawings by Duane Bibby foreword by Gerald J. Sussman 1995 ISBN 0-262-56099-2 216 pp. 12 illus. $17.50 (paper) that imho is much more appropriate as a learning tool for scheme (or lisp, in general) note also that it cost substantially less!
Hopefully one day someone will determine why and fix it! Until then, however, use gimp-image-remove-layer instead of gimp-layer-delete and things should work fine.
To date, there's no native port for older Macs. Work has been done on OS X and to work with X11 on Macs, with Tenon's X port, etc. For details go to http://www.macgimp.com/ .
You downloaded a non-Windows version. The Windows version is available at http://www.gimp.org/win32/ .
To avoid problems with GIF's patent holder, the GIMP no longer ships with GIF support by default. If you can't find the GIF plug-in wherever you got the GIMP, it's available at http://www.gimp.org/win32/ .
ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz
If you are using a 64-bit OS, you need to add the `-o32' option for the compiler, or use gcc. With the SGI compiler, you may also need to play with optimization. Some modules may have exhibit problems unless compiled with `-O1' or even `-O0'.
Script-Fu requires the POSIX-compliant regex functions, which SGI only supports with IRIX 6.2 and later versions. The GNU version of regex should work just fine, though, and is available at:
http://wuarchive.wustl.edu/systems/gnu/regex-0.12.tar.gz
The GIMP is interacting in such a way with your system that it thinks you have XIM extensions when you don't. Run the configure script again, with the `--disable-xim' option, and recompile.
You can also try compiling with `--disable-shared'.
Or you can install a version of X11R6. 8^)
If you just want to use freefonts or sharefonts, you can copy these files into the appropriate directory (such as /usr/openwin/lib/fonts/freefonts/ or /usr/openwin/lib/fonts/sharefonts/), or merge them with the appropriate fonts.dir and fonts.scale files if you mixed in freefonts and sharefonts with existing fonts:
Or just try using fontadmin instead of
mkfontdir .
I've never run into a Solaris system missing this, but according to Neil Corlett:
The 'fontadmin' tool is a openwin demo program and sometimes does not exist. To properly add fonts the finagled directory requires fonts.dir, fonts.scale files to exist. mkfontdir does the first of these OK. For the second I built groff and downloaded type1inst-0.6.1 from an X contrib archive. type1inst (which needs groff) will build the fonts.scale file from the pfb files automatically.Solaris 2.6 is supposed to include better font editor and admin tools.
There may be a number of reasons. Several peoples' answers are here. The most detailed answers, list first, are the best bets with their noted versions.
According to resident Gimp on SOlaris guru Jim Harmon, more recent versions (0.99.25 on) should compile easily, but you may need to make a change in /usr/graphics/gtk-config.in:
OLD:
--libs)
echo -L${exec_prefix}/lib -L/usr/openwin/lib -R/usr/openwin/lib \
-lgtk -lgdk -lglib -lXext -lX11 -lsocket -lnsl -lm
;;
NEW: (subs. your own GTK path for /usr/graphics )
--libs)
echo -L${exec_prefix}/lib -L/usr/openwin/lib -R/usr/openwin/lib \
-L/usr/graphics/gtk+-0.99.10/gtk/.libs \
-R/usr/graphics/gtk+-0.99.10/gtk/.libs -lgtk \
-L/usr/graphics/gtk+-0.99.10/gdk/.libs \
-R/usr/graphics/gtk+-0.99.10/gdk/.libs -lgdk \
-L/usr/graphics/gtk+-0.99.10/glib/.libs \
-R/usr/graphics/gtk+-0.99.10/glib/.libs -lglib \
-lXext -lX11 -lsocket -lnsl -lm
;;
Jim Harmon compiled GIMP 0.99.19 and GTK+ 0.99.5 on Solaris 2.5, SPARC 5. Here are the steps he took:
(*) If you're installing a NEW VERSION, first:
(*) o cd <gtk install path> (/usr/graphics/gtk+<ver>)
(*) o make uninstall clean
(*) o rm -r ~/.gimp
THEN:
o mkdir /usr/graphics
o mv g*.tar.gz /usr/graphics
o tar xvfz gtk+-0.99.5.tar.gz
created /usr/graphics/gtk+-0.99.5
o cd gtk+-0.99.5
o ./configure, make, make install
(executed successfully)
o cd ..
o tar xvfz gimp+-0.99.19.tar.gz
created /usr/graphics/gimp+-0.99.19
o cd gimp+-0.99.18
o ./configure
NOW: *** Edit "config.status" ***
o vi config.status
/LDFLAGS
o change:
(note, the following are SINGLE LINES, remove any "\"
characters and duplicate objects in the string if you
cut/paste these into your config.status file...)
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib \
-lgtk -lgdk -lglib \
-lXext -lX11 -lsocket -lnsl -lm%g
to:
(*) s%@LDFLAGS@% -L/usr/local/lib -R/usr/local/lib \
-L/usr/openwin/lib -R/usr/openwin/lib \
-L/usr/graphics/gtk+-0.99.5/gtk/.libs \
-R/usr/graphics/gtk+-0.99.5/gtk/.libs -lgtk \
-L/usr/graphics/gtk+-0.99.5/gdk/.libs \
-R/usr/graphics/gtk+-0.99.5/gdk/.libs -lgdk \
-L/usr/graphics/gtk+-0.99.5/glib/.libs \
-R/usr/graphics/gtk+-0.99.5/glib/.libs -lglib \
-lXext -lX11 -lsocket -lnsl -lm%g
(*) O To SAVE SPACE in compiling, in the config.status file,
REMOVE the "-g" option from the CFLAGS line:
[was] s%@CFLAGS@% -g -I/usr/openwin/include -O2 -Wall%g
[is] s%@CFLAGS@% -I/usr/openwin/include -O2 -Wall%g
o ./config.status, make, make install
(In other words, where "-lgtk -lgdk -lglib" appear
on the LDFLAGS line, add the GTK+ path to the libs
with the format of "-L/usr/graphics/gtk+-0.99.3//.libs
-R/usr/graphics/gtk+-0.99.3//.libs -l", subsituting
gtk/gdk/glib for )
(*) Also bear in mind that "/usr/local/lib" won't exist if not
added as shown to LDFLAGS.
- - -
CAVEATS:
I'm using the precompiled GCC 2.7.2.3 for Solaris 2.6,
and gmake instead of make. To get GCC and GMAKE working,
I had to set the paths to /usr/xpg4/bin and /usr/ccs/bin
to the PATH variable, so that different compiler tools
could be found. (ar, bison, cpp, etc.)
Jim Harmon compiled GIMP 0.99.18 and GTK+ 0.99.3 on Solaris 2.5, SPARC 5. Here are the steps he took:
o mkdir /usr/graphics
o mv g*.tar.gz /usr/graphics
o tar xvfz gtk+-0.99.3.tar.gz
created /usr/graphics/gtk+-0.99.3
o cd gtk+-0.99.3
o ./configure, make, make install
(executed successfully)
o cd ..
o tar xvfz gimp+-0.99.18.tar.gz
created /usr/graphics/gimp+-0.99.18
o cd gimp+-0.99.18
o ./configure
NOW: *** Edit "config.status" ***
o vi config.status
/LDFLAGS
o change:
(note, the following are SINGLE LINES, remove any
<CR> characters in the string if you cut/paste it into your
config.status file...)
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lglib
-lXext -lX11 -lsocket -lnsl -lm%g
to:
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib
-L/usr/graphics/gtk+-0.99.3/gtk/.libs
-R/usr/graphics/gtk+-0.99.3/gtk/.libs -lgtk
-L/usr/graphics/gtk+-0.99.3/gdk/.libs
-R/usr/graphics/gtk+-0.99.3/gdk/.libs -lgdk
-L/usr/graphics/gtk+-0.99.3/glib/.libs
-R/usr/graphics/gtk+-0.99.3/glib/.libs -lglib -lXext -lX11 -lsocket
-lnsl -lm%g
o ./config.status, make, make install
(In other words, where "-lgtk -lgdk -lglib" appear
on the LDFLAGS line, add the GTK+ path to the libs
with the format of "-L/usr/graphics/gtk+-0.99.3/<lib>/.libs
-R/usr/graphics/gtk+-0.99.3/<lib>/.libs -l<lib>", subsituting
gtk/gdk/glib for <lib>)
--------------------------------
CAVEATS:
I'm using the precompiled GCC 2.7.2.3 for Solaris 2.6,
and gmake instead of make. To get GCC and GMAKE working,
I had to set the paths to /usr/xpg4/bin and /usr/ccs/bin
to the PATH variable, so that different compiler tools
could be found. (ar, bison, cpp, etc.)
According to Keyyly Price, here's a major one for 0.99.10 .
``If you do a -lX11, you must also include -lsocket, or it won't compile anything of X on Solaris 2.5. X doesn't have the socket lib.
Which means you'll need to setenv LIBS -lsocket while running configure if you run Solaris 2.5.''
Will Lowe did the following to get the GIMP compiled for Solaris 2.5.1 : (You should replace /usa/lowe/usb_lowe/gimp in each "-L" part with whereever you are compiling gimp, and replace /usa/lowe/gimp/lib in the "-R" parts with whereever you're going to install gimp. -Will)
Get gimp source (duh) (gimp-0.99.9).
uncompress and untar the source.
./configure --without-libtiff
rm docs/pdb.info
gimp/gtk+/gdk/gdkimage.c
Remove these three lines:
#if defined (HAVE_IPC_H) && defined (HAVE_SHM_H) && defined (HAVE_XSHM_H)
#define USE_SHM
#endif
gimp/gtk+/gdk/Makefile:
change the variable "libgdk_la_LDFLAGs" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/glib/.libs -R/usa/lowe/gimp/lib
before "-lglib"
gimp/gtk+/gtk/Makefile:
change the variable "libgtk_la_LDFLAGS" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/gdk/.libs -R/usa/lowe/gimp/lib
before "-lgdk"
gimp/libgimp/Makefile:
change the variable "libgimp_la_LDFLAGS" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/glib/.libs -R/usa/lowe/gimp/lib
before "-lglib"
change "libgimpui_la_LDFLAGS" to include
-L/usa/lowe/usb_lowe/gimp/gtk+/gtk/.libs -R/usa/lowe/gimp/lib
before "-lgtk"
gimp/plug-ins/dgimp/dgimp.c
move "#include <sys/types.h>" to above "#include <sys/socket.h>"
gimp/plug-ins/dgimp/lpg.c
same as dgimp.c
For 0.99.pre11, Sheldon E. Newhouse suggests the following
change to the libtool files:
#archive_cmds='$LD -G -z text -h $soname -o $lib$libobjs$deplibs' archive_cmds='$LD -G -h $soname -o $lib$libobjs$deplibs'
SunOS ships with an X11R4 server, which does not handle either scaleable fonts or communications with the X font server. If you want to use the freefonts (or any scalable fonts) on SunOS, you need to install your own, newer X server, preferably X11R6.4 (which will be much faster than the server shipped with SunOS).
If you do this, you will no longer have PostScript capability directly in your X server; you will need to use ghostscript. You may well want to keep both servers around, and use each when you need its features.
Of course, you could always try to find a PS version of the font you need and make a bitmap for the size you need and add that to the X11R4 server's font path, but if you need more than one or two font/size combinations over all the time you use GIMP, this is an obnoxious solution.
Yes. Try the following:
ftp://ftp.gimp.org/pub/gimp/binary/RPMS/
ftp://s9412a.steinan.ntnu.no/pub/gimp/
According to Rob Payne...
There are old .src.rpm's on ftp.redhat.com for gimp and gtk that if used to build new gtk+ and gimp will create all kinds of headaches for the builder.
The gtk SPEC file manually moves header files from gtk default installation place, and then the CFLAGS returned by gtk-config are incorrect when it comes time to build/install gimp. I was successful in bringing the gtk+ SPEC file up to date by removing the following lines from (gtk-970925.spec) to build 0.99.7 and 0.99.8:
(cd $RPM_BUILD_ROOT/usr/local/include
mkdir glib
mv glib.h glibconfig.h glib)
Of course, the %files section of that SPEC need to be changed, as well to
include the differences in places for the header files, and to include
gtk-config.
I hope that information is useful to someone. If you have any questions about any of this, please let me know.
Another possibility is for this error (far less common) is that there is an old library compiled with the other hanging around somewhere on the system. Remove old copies of libgimp.
You probably just installed the graphics libraries. You also need to install the development portion as well; it's called the libgr source package. After installing that, GIMP should compile easily.
``Some of the X include files and libraries are not in /usr/include/X11 and /usr/lib/X11 as you may expect. This is because HP allows support for X11R4 and X11R5 on the same machine. You must modify a configuration file so that the Makefile created by imake looks for these files and libraries in an alternate location. See "Motif and Xt" on page A-5 and "Xaw and Xmu" on page A-6 for details on installation of OSF/Motif, Xt, Xaw and Xmu.
...
``HP does not ship or support these widget libraries; however, they are widely used for X public domain software. Binaries and header files are available from the Interworks library. Source is available from public domain archives. The name of the binary package in the Interworks library is x8.0s700.tar.Z. You may also be able to locate these files on another machine and copy them to your machine.''
The ref'd package is at:
ftp://www.interworks.org/pub/comp.hp/
Look for the x8.0s[378]00.tar.Z files.
You are probably not using the GNU make. Most, if not all, non-GNU makes will fail on the GIMP makefiles. Get the GNU make package.
It's a bug in AcceleratedX with shared memory. Turn off shared memory when you start the GIMP (--no-xshm) or pick up the patch to AcceleratedX's X server from ftp://ftp.xinside.com/pub/update/ .
At least one person has found this bug (or another one with the same symptoms) to still be present in 4.1 .
This is a bug in XFree. You need to upgrade to XFree3.3.2 .
Contributors: Spencer Kimball & Peter Mattis, Thomas Bahls, Zach Beane, Giacomo Boffi, Victor Brilon, Eli Burke, Seth Burgess, Keith Christian, Branko Collin Neil Corlett, Christopher Curtis, Robert Dinse, Bert Driehuis, Ian Donaldson, Pat Dunn (?), Stephen Eglen, Eugene Filippov, Rial Fletcher, Steve Ginzburg, Trond Eivind Glomsrĝd, Dov Grobgeld, Michael J. Hammel, Pete Harlan, Jim Harmon, Thimo Jansen, John Johnson, Philippe Lavoie, Marc Lehmann, Adrian Karstan Likins, Will Lowe, Ingo Lütkebohle, T. Paul McCartney, Adam Moss, Tim Mooney, Sven Neumann, Sheldon E. Newhouse, Miles O'Neal, Rob Payne, Mark Powell, Quartic (Federico Mena), Deon Ramsey, Juergen Schlag, William L. Sebok, Terrelle Shaw, Manish Singh, Mike Sweet, Eiichi Takamori, Mike Taylor, Owen Taylor
Last updated: 04 April 2002
Copyright 1996-1998
Miles O'Neal,
<meo@rru.com>
Austin, TX. All rights reserved. You may freely redistribute this
FAQ so long as you redistribute it in its entirety, including this
notice and the web location of the latest version. You are not
required to redistribute the graphics with ths FAQ. It would be
much appreciated if you let the FAQ maintainer (Miles O'Neal)
know if you redistribute this FAQ.
Web service donated by Net Ads
as a community service.