Compilation problems ...
Dear listmembers, I have successfully compiled gimp 1.2.0 on SuSE 7.0. However, I had to face some difficulties during the compilation and installation process I document fyi with the files I attached. I shortended them to not be boring anyone with miles of messages of successfully compiled files ;-) Basically the following behaviour could be observed: "make" crashes at the FIRST RUN saying that gimpwidgets.o would not exist - even though it does. Running "make" a second time runs smooth - no problems. "make install" crashes always at the FIRST RUN saying: ln -s ../../dialogs /usr/share/gimp/1.2/help/C/toolbox/help/dialogs ln: cannot create symbolic link `/usr/share/gimp/1.2/help/C/toolbox/help/dialogs ' to `../../dialogs': No such file or directory running "make install" a second time THIS location is crossed, however, such errors occur nine times at nine different locations in the makefile (it was somewhat boring to get the installation through ...). Because it is a help-related error I didn´t pay too much attention to it. Can anybody explain to me what is going wrong? Do I use a too old make, a too old ln - or is this a real issue of gimp? I attached excerpts of the files I found after make errorlog 21 (errorlog-compile-1.2.0.gz, 1 compile-error) and make install instlog 21 (instlog-compile-1.2.0.gz, 9 installation errors) Please mail back directly because I am no member of the mailing list. Anyway, many many thanks for your efforts - and many thanks for a wonderful program. Take care Dieter Jurzitza --- E-Mail: Dr. Ing. Dieter Jurzitza [EMAIL PROTECTED] Date: 04-Jan-01 Time: 14:33:05 | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / °°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) instlog-compile-1.2.0.gz errorlog-compile-1.2.0.gz
Re: Compilation problems ...
[snip] Basically the following behaviour could be observed: "make" crashes at the FIRST RUN saying that gimpwidgets.o would not exist - even though it does. Running "make" a second time runs smooth - no problems. "make install" crashes always at the FIRST RUN saying: ln -s ../../dialogs /usr/share/gimp/1.2/help/C/toolbox/help/dialogs ln: cannot create symbolic link `/usr/share/gimp/1.2/help/C/toolbox/help/dialogs ' to `../../dialogs': No such file or directory [snip] I'm not an expert, but what version of GTK do you have? You need 1.2.8, it will not work with 1.3 developer versions. I don't think that that's it, because I think you would have gotten other errors too then, but since it complains about the widgets it's a possibility. Lourens
A decouvrir
Title: Changer de salon n'est plus un luxe ! Allez voir vous serez surpris WWW.PROMOCANAPE.com Plus de 150 modèles Pas dintermédiaires + Pas de stock = 30 % à 50 % moins cher Ci-joint une photo de lun de nos modèles: Canapé 3 places cuir à seulement 4510,00 francs Voulez vous recevoir notre catalogue? mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 371.jpg
Re: perl script in gimp for Windows : is it possible ?
Marc Lehmann writes: - Makefile.PL wants to use gtk-config. No such on Win32. (How could there be one? On Win32, people typically don't build GTK+ themselves, but fetch the headers and libraries The same, of course, is true for the gimp. most people who build gimp would be able to build gtk as well ;) gtk-config (or glib-config) is not a problem for people who *build* glib and/or gtk+ themselves, they know where they are going to install it, and they could generate a suitable *-config script. The problem is producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application. This is, of course, not solvable in any case. Changing the compiler means that all the autodetected stuff goes wrong. It isn't necessarily that bad, remember that mingw and MSVC use the same runtime, and all header files that are present in MSVC have clones in mingw. Most autodetected stuff is equally valid for mingw and MSVC. (One difference is that gcc uses long long and the LL suffix for long long literals, MSVC uses __int64 and the i64 suffix. The corresponding printf format is obviously the same, though, as the C library is the same.) This also means that the compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the same. Wrong. Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care either. We have a lot of problems with this (obvious for me but not others it seems), e.g. on IRIX where the preinstalled perl is compiled with the commercial sgi compiler but most people only have access to gcc (which is not compatible). On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is another matter). The bleeding edge of binutils (which I personally don't use yet) can even link to DLLs directly (autogenerating import libraries on the fly), or use libraries in MS's format. The better option IMHO would be to make glib (source available!) compilable against perl, as a compatibility measure on win32. Yes, the dirent emulation is GLib has caused some problems before, as it isn't the same emulation as that in the libmingw32 library (which the mingw gcc automatically links with). I will probably move the dirent stuff out to a separate library (so that it is available for MSVC users), and make it identical to the one in libmingw32. (I think it was wrong to include dirent emulation in libmingw32, and a dirent.h header, as that breaks being able to compile the same code with either gcc or MSVC.) Certainly. Also not concentrating on gtk-perl but instead on gimp-perl would also help. I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl is a prerequisite. OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. This most likely will change at some point when I have the time to look into it. One problem I can think of right now is that the gimp modules want to use entry points in the gimp executable, and for that to work on Win32 you must mark those entry points for export when building the exe. I.e. build the exe kinda like you would build a DLL. There is no mechanism in auto* or libtool to handle that, I think. It now seems as it indeed would be easier to use a Perl running on cygwin to produce the Makefiles for Gtk-Perl and Gimp-Perl (Makefiles for GNU Make and a cygwin shell), but still have those Makefiles run the mingw gcc. (That's the kind of Makefiles I build GLib, GTK+ and GIMP with.) --tml
Re: how to use *.pfb-fonts?
Max Moritz Sievers said... | |I want to use the freefonts from the contrib-directory. These fonts are |pdf-fonts like those in /usr/X11R6/lib/X11/fonts/Type1/ but I can't use |them in Gimp (and any other application) (after copying them to this |directory). |Gimp displays only the fonts in /usr/X11R6/lib/X11/fonts/100dpi and |/usr/X11R6/lib/X11/fonts/75dpi. Did you read through the FAQ, and follow the directions there for getting the fonts to work? http://www.rru.com/~meo/gimp/ -Miles
Re: perl script in gimp for Windows : is it possible ?
On Fri, Jan 05, 2001 at 02:44:42AM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote: producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application. Well, I thought that people capable of building gimp (in win32 this is not common ;) could build gtk+ as well, but in general (when gimp for win32 is being built by millions of users wordlwide) this is a hindrance. However, when it is possible to create downloadable binary distributions for linux it should not be that difficult to do so for windows as well (c:\gnu\gtk+ required ;) But I am slowly beginning to see some of the win32 problems. and MSVC. (One difference is that gcc uses long long and the LL suffix for long long literals, MSVC uses __int64 and the i64 suffix. The It's just a matter of time for msvc to support C, though, so even this difference will soon vanish (or so). corresponding printf format is obviously the same, though, as the C True, but the commandline switches are not (just on of the problems we have on irix, for example, as gimp-perl links against perl AND gimp, and both worlds (perl/libtool) might have different ideas on how to do so). Wrong. Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care either. Hmmm.. what if perl tells me to link against c:\perl\perl.lib but gcc does not like this on it's commandline? On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is yes, but msvc isn't and when you pick, e.g. activestate as your perl then you are pretty much tied to msvc for gimp as well. everything else will end up in a ral nightmare, as you found out ;) (I think it was wrong to include dirent emulation in libmingw32, and a dirent.h header, as that breaks being able to compile the same code with either gcc or MSVC.) I also think it was bad for PDL to include the ppport.h header file, as gimp-perl does the same ;- What's even worse is the config-trickery I do in the makefile to increase the chances of libtool and perl coexisting. It *is* a crual world, even under unix I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl is a prerequisite. No. gimp-perl will detect (not using autoconf this time) wether Gtk is installed and will not try to do anything graphically if it isn't. This means thast many scripts will run with default values (somewhat useful) and the ones depending on Gtk will not be instaled, but scriptability is still 100%. Extra prizes if the Perl-Server will run (it uses unix domain sockets ;), but that one is not required either. OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. Now that's cool! Is that an art form? ;) Whew. to look into it. One problem I can think of right now is that the gimp modules want to use entry points in the gimp executable, and for that Given that the next version of gimp might make extensive use of modules, this will be a problem. building the exe. I.e. build the exe kinda like you would build a DLL. There is no mechanism in auto* or libtool to handle that, I think. Ah, so the tools you switch *to* lack the support to do what you need ;) A cruel world. My personal problem with libtool (and to a lesser extent automake) is that tehy are *very* narrow-minded. They insist on the smallest possible subset. For example, I often want to build shared libraries without -fpic since this works under any platform I care for. It doesn't allow this. What's even worse, I often just *know* that I can link against that libperl.a file but libtool refuses because it simply will not link against .a files. It now seems as it indeed would be easier to use a Perl running on cygwin to produce the Makefiles for Gtk-Perl and Gimp-Perl (Makefiles for GNU Make and a cygwin shell), but still have those Makefiles run the mingw gcc. (That's the kind of Makefiles I build GLib, GTK+ and GIMP with.) All that's needed would be a perl ported to mingw32. As I udnerstand it, mingw is just a gcc that threw away POSIX and gives you a "standard" win32 build environment. So what is needed is a perl that expects the windows environment and a unix build environment. On CPAN I cna only find the "standard" (a.k.a. "perl") and "activestate" ports. I looked at the "standard" README.win32 and it seems to be a truely native port, it works with borland, msvc AND: Mingw32 with GCC version 2.95.2 or better The last of these is a high quality freeware compiler. Support for it is still experimental. (Older versions of GCC are known not to work.) This port currently supports MakeMaker (the set of modules that is used to build extensions to perl). Therefore, you should be able to build and install most extensions found in the CPAN sites. See LUsage Hints
