Re: Bug in configure
"Uwe Koloska" [EMAIL PROTECTED] writes: "./configure --help" gives a wrong default for "--enable-gimpdir": --enable-gimpdir=DIRchange default gimpdir from .gimp to DIR must be .gimp-1.2 Same change in INSTALL. (I don't know wether I can use variables, so I can't make a patch) you can't use variables in INSTALL (but we could make an INSTALL.in to generate INSTALL from), so I changed it by hand there. Using variables should work in configure.in, but obviously not in the output of AC_ARG_ENABLE, so my quick fix was to hardcode the value as well. Thanks for the report. Salut, Sven
configure
There seems to be a problem in configure. If I use a freshly installed Linux without the headers of the kernel sources installed, configure runs without any error, but doesn't define certain variables. So the whole couldn't compile. The thing is that configure should check for the headers of the kernel sources. -- Sent through GMX FreeMail - http://www.gmx.net
Re: configure
Martin Weber [EMAIL PROTECTED] writes: There seems to be a problem in configure. If I use a freshly installed Linux without the headers of the kernel sources installed, configure runs without any error, but doesn't define certain variables. So the whole couldn't compile. The thing is that configure should check for the headers of the kernel sources. A linux installation without kernel headers can not be called "a freshly installed Linux". In fact it's an "incompletely installed Linux" at least if you intend to compile stuff on this box. The distribution (or the user himself) should take care of installing appropriate header files when installing the compiler. It's not Gimp's job to take care of each and every thing a dumb user could do wrong. Salut, Sven
Bug in configure
Hello, "./configure --help" gives a wrong default for "--enable-gimpdir": --enable-gimpdir=DIRchange default gimpdir from .gimp to DIR must be .gimp-1.2 Same change in INSTALL. (I don't know wether I can use variables, so I can't make a patch) maybe it would be a good idea, to explain that gimpdir is the personal dir and does not affect the global dirnames. Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: strange configure errors with perl in 1.1.29
On Mon, Nov 06, 2000 at 03:23:32PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: I suppose that on most other systems, "perl5" is newer or the same as "perl", so the current test in configure.in is probably the best solution (and it has been like that for more than two years). You can consider this bug report closed. Well, I wrote that at a time where perl4 was quite common on unix (not linux), since most vendors ship /usr/bin/perl (4). If anybody has some data about commercial unixes and their version of pelr shipped (and if that is perl5) I'd be more than happy to get rid of that uglieness in favour of the more standard "perl" + "fix your path, pal". -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: configure, libtool the install prefix [2]
On Mon, 2 Oct 2000 [EMAIL PROTECTED] wrote: We build the gimp-perl plugin from the CPAN sources and disable it in the GIMP distribution because it makes too much problems there especially on recent SPARCs, alphas and ia64. We don't use the BuildRoot features of RPM however because it has some issues with Perl which Marco also found :) Ok, you're right, but why everything worked fine till gimp 1.1.24 (the last RPM I've built through the "standard" gimp.spec)? I don't think that dropping the RPM support or a clean and easy way for RPMming the GIMP is a good choice (none would use the "prefix" for a normal installation except the ones who would build a binary rpm). ;) Happy GIMPing, Marco -- //\/\ Marco (LM) Lamberto e-mail:[EMAIL PROTECTED] (remove 'nOsPaMz-') The Sunny Spot - http://www.geocities.com/Tokyo/1474/
Re: configure, libtool the install prefix [2]
On 1 Oct, Marc Lehmann wrote:
I haven't fixed yet the GIMP Perl plugins installation, please could
anyone fix it or tell me a workaround?
The README.perl suggests PREFIX= for just this case. Daniel Egger
could probably get more info as he works for suse and suse has quite a
few perl packages in rpm format (includign gimp-perl).
We build the gimp-perl plugin from the CPAN sources and disable it in
the GIMP distribution because it makes too much problems there especially
on recent SPARCs, alphas and ia64. We don't use the BuildRoot features
of RPM however because it has some issues with Perl which Marco also
found :)
The important section from the gimp-perl package looks like this:
%build
CFLAGS="-DGIMP_ENABLE_COMPAT_CRUFT" perl Makefile.PL
make
%install
eval `perl -V:installarchlib`
rm -f $installarchlib/perllocal.pod
make install
install -d /var/adm/perl-modules
mv $installarchlib/perllocal.pod /var/adm/perl-modules/gimpperl
%{?suse_check}
whereas the necessary BuildRoot stuff from the MIME-Base64 Perl package
looks like this:
%build
perl Makefile.PL
make
%install
rm -rf $RPM_BUILD_ROOT
eval `perl -V:installarchlib`
install -d $RPM_BUILD_ROOT/$installarchlib
make PREFIX=$RPM_BUILD_ROOT/usr \
INSTALLMAN1DIR=$RPM_BUILD_ROOT/%{_mandir}/man1 \
INSTALLMAN3DIR=$RPM_BUILD_ROOT/%{_mandir}/man3 \
install
install -d $RPM_BUILD_ROOT/var/adm/perl-modules
mv $RPM_BUILD_ROOT/$installarchlib/perllocal.pod $RPM_BUILD_ROOT/var/adm/perl-mo
cd $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/5.*/*-linux/auto/MIME/Base64
cat .packlist | sed s:$RPM_BUILD_ROOT:: | sort -u .packlist.n
mv .packlist.n .packlist
cd $RPM_BUILD_ROOT/var/adm/perl-modules/
cat MIME-Base64 | sed s:$RPM_BUILD_ROOT:: MIME-Base64.n
mv MIME-Base64.n MIME-Base64
Using PREFIX for installation doesn't seem to work for all packages,
though...
--
Servus,
Daniel
configure, libtool the install prefix
I've got a little trouble while rebuilding the rpm of gimp 1.1.26, when running
the "make prefix={a_new_prefix} install" it tries to install into "/usr"
discarding the "prefix" and "PREFIX" values.
I should update someting or someone has forgotten something? ;)
Actually I've installed the following tools:
autoconf-2.13
libtool-1.3.4
automake-1.4
Happy GIMPing,
Marco
--
//\/\ Marco (LM) Lamberto
e-mail:lm(at)geocities.com (replace '(at)' - '@')
The Sunny Spot - http://www.geocities.com/marcolamberto/
Re: configure, libtool the install prefix
On 1 Oct, Marco Lamberto wrote:
I've got a little trouble while rebuilding the rpm of gimp 1.1.26,
when running the "make prefix={a_new_prefix} install" it tries to
install into "/usr" discarding the "prefix" and "PREFIX" values. I
should update someting or someone has forgotten something? ;) Actually
You shouldn't use make prefix=something install. This is mostly useful
for buildrooting rpms but may produce silly results for everything else
(because programs may have a different prefix hammered in at configure time).
So if you want to get GIMP to a different place use: configure --prefix=something
and then: make install.
--
Servus,
Daniel
Re: configure, libtool the install prefix [2]
On Sun, Oct 01, 2000 at 09:55:33PM +0200, Marco Lamberto [EMAIL PROTECTED] wrote: I haven't fixed yet the GIMP Perl plugins installation, please could anyone fix it or tell me a workaround? The README.perl suggests PREFIX= for just this case. Daniel Egger could probably get more info as he works for suse and suse has quite a few perl packages in rpm format (includign gimp-perl). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Configure --with-mp=yes Who wants it?
Jay Cox wrote: Jon Winters wrote: Hi, Here is a screengrab if anyone is interested... [Jon Winters had reproduced #10595 with 1.1.25 distribution GRO] http://www.obscurasite.com/images/screengrabs/funky-tots.jpg Enjoy! EEK! I hope that isn't from the "fixed" version. I was hoping that it would fix that problem too. I still can't reproduce it here, but I only have the "fixed" version now. Jay Cox [EMAIL PROTECTED] Appears that your fix for #24188 also lays to rest #10595; I can reproduce neither phenomena this morning on the SGI and Linux machines with the new code and a complete rebuild. I think you bagged both. Congratulations. Interesting if Seth and Jon can confirm on #10595 and perhaps Thaddeus Parkinson [EMAIL PROTECTED] on his #24188. We should all keep an eye out for Tigert's thread dying message, as well. Be good, be well Garry
Re: Configure --with-mp=yes Who wants it?
"Garry R. Osgood" wrote: #10595 addenda snipped: see http://bugs.gnome.org/db/24/24188.html For the (speculative) 1.2 release: 1. Do we support this option (and fix the bugs)? 2. or do we shut down option --with-mp=yes ? Leaving the situation as-is I regard unacceptable for 1.2 release. Those with multiple CPU's will be naturally attracted to the switch, unlimiting the set of people affected in short order. What's not functional should not be offered, so either a fix or an option removal seems in order. How should cleanup proceed? Be good, be well Garry Osgood I just checked in a fix for #24188. I could never reproduce #10595, but I'm using a single processor machine. If those of you with MP machines could beat on it for a while and report back how it works for you I would appreciate it. I don't think we should remove MP mode quite yet, but I am rather biased. Jay Cox [EMAIL PROTECTED]
Re: Configure --with-mp=yes Who wants it?
I've got a multiprocessor machine. What exactly do I need to do to test this stuff? I haven't been following the entire thread. I should... ./configure --with-mp=yes Then do make and make install correct? Then what??? Just use gimp or do something specific to test. I think SMP optimization is important. The future of Gimp depends on it. we want Gimp to dominate on that new cube from Sony with 64 PSX2 processors. 8-) -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Configure --with-mp=yes Who wants it?
Hi, Brief investigations confirm that two bugs, #10595 [gimp-bug] Tile Rendering not working with erasure], reported by Seth Burgess [EMAIL PROTECTED] http://bugs.gnome.org/db/10/24188.html #24188 [gimp-bug] Tile Rendering not working with erasure[gimp-bug] image *still* not properly displayinglayer mode, reported by Thaddeus Parkinson [EMAIL PROTECTED] http://bugs.gnome.org/db/24/24188.html occur only when gimp is built with configure option --with-mp=yes. (multiprocessor support). #24188 substantially compromises Gimp functionality: In new images, layers with properties other than "Normal" or "Dissolve" become invisible. Seth Burgess wrote [in Re: Bug#10595: [gimp-bug] Tile Rendering not working with erasure] Yes, we did discuss that briefly... [At Berlin GimpCon - GRO] is this bug worth tracking down as it is a very limited set of people affected? Seth #10595 addenda snipped: see http://bugs.gnome.org/db/24/24188.html For the (speculative) 1.2 release: 1. Do we support this option (and fix the bugs)? 2. or do we shut down option --with-mp=yes ? Leaving the situation as-is I regard unacceptable for 1.2 release. Those with multiple CPU's will be naturally attracted to the switch, unlimiting the set of people affected in short order. What's not functional should not be offered, so either a fix or an option removal seems in order. How should cleanup proceed? Be good, be well Garry Osgood
Re: configure script missing
Vikas wrote: snipped historical stuff... I even ran autoconf on the directory and it did generate the configure script but the script did not run. There were errors at startup itself. I do not remeber them right now. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Hi, Typically, I run autogen.sh --prefix=/usr/people/garry/WorkSpace/dist \ --with-gtk-prefix=/usr/people/garry/WorkSpace/dist \ --enable-ansi \ --enable-debug \ --disable-static \ --disable-perl autogen.sh is designed to run autoconf, automake, libtool, gettext. then kick off configure, passing the parameter list to that script, as noted by Marc and described in gimp/HACKING (was that available to you to read?). None of the options I use above is mandatory; the first two assist me in keeping a development gimp environment that is distinct from a production gimp, the next three assist in debugging, the last concerning a regrettable difficulty specific to SGI/Irix (See bug report: http://bugs.gnome.org/db/193/19335), and which is approaching resolution. I suggest you experiment with autogen.sh, as described in gimp/HACKING. If you care to, send me the output by private e-mail if you do not have any success. Be good, be well Garry Osgood
configure script missing
I downloaded entire CVS'ed sources of GIMP and to start I could not find configure script. Can anybody send me that file or tell me where can I find it other that doing CVS again (It is a long job). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: configure script missing
On Wed, Sep 06, 2000 at 12:14:50PM +0530, Vikas [EMAIL PROTECTED] wrote: I downloaded entire CVS'ed sources of GIMP and to start I could not find configure script. Can anybody send me that file or tell me where can I find it other that doing CVS again (It is a long job). Run autogen.sh as if it were configure. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: configure script missing
Vikas wrote: I downloaded entire CVS'ed sources of GIMP and to start I could not find configure script. Can anybody send me that file or tell me where can I find it other that doing CVS again (It is a long job). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com Hi, Welcome to the bleeding edge. CVS gimp does not have "configure" in the CVS repository because it is generated from "configure.in" More generally, to work with CVS Gimp, you may need additional "maintainer" tools (check, though, because you may already have them) GNU autoconf, GNU automake GNU libtool, GNU gettext. Read gimp/HACKING in your CVS working directory on how to use these tools to generate your local configure script. To learn more about using CVS, I'd suggest "Open Source Development with CVS" by Karl Fogel (1999 Coriolis Open Press). Significant parts of this book is available online at http://cvsbook.redbean.com. Be good, be well Garry Osgood
Re: configure script missing
"Garry R. Osgood" wrote: Vikas wrote: I downloaded entire CVS'ed sources of GIMP and to start I could not find configure script. Can anybody send me that file or tell me where can I find it other that doing CVS again (It is a long job). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com Hi, Welcome to the bleeding edge. CVS gimp does not have "configure" in the CVS repository because it is generated from "configure.in" More generally, to work with CVS Gimp, you may need additional "maintainer" tools (check, though, because you may already have them) GNU autoconf, GNU automake GNU libtool, GNU gettext. I even ran autoconf on the directory and it did generate the configure script but the script did not run. There were errors at startup itself. I do not remeber them right now. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: installation in non-standard location / configure bug
On Mon, 29 May 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Sun, May 28, 2000 at 06:46:43PM -0400, Warren Hedley [EMAIL PROTECTED] wrote: Also, configure ignores the perl executable argument specified in the --enable-perl option (see configure line above, for example), The --enable-perl option specifies the perl prefix to install the pelr modules, not the perl executable path. Specifying a file will be disastrous. I think that the option should be named "--enable-perl-prefix" instead of the shorter "--enable-perl", in order to avoid confusion. This would be more consistent with the other options, and longer names are not a problem because they are not used very often anyway. The help string should then be changed to "--enable-perl-prefix=PFX". If someone wants an option to specify the path to the perl executable, then it should be "--with-perl=...". Maybe adding the "--with-perl" option would make people think twice before making incorrect assumptions? -Raphael
Re: installation in non-standard location / configure bug
Marc Lehmann wrote: The --enable-perl option specifies the perl prefix to install the pelr modules, not the perl executable path. Specifying a file will be disastrous. Doh. OK - I didn't read that very closely. I think that the option should be named "--enable-perl-prefix" ... If someone wants an option to specify the path to the perl executable, then it should be "--with-perl=...". ... Hear hear - now that's a good idea. -- Warren Hedley Department of Engineering Science Auckland University New Zealand
installation in non-standard location / configure bug
I've just compiled and installed gimp 1.1.22 under Irix, but have done so in a non-standard (ie. not /usr/local) location so as not to interfere with other users on the network. My problem is that the executable seems to expect user_install to be in /usr/local. I get this message when it starts trying to create my personal directories /usr/local/share/gimp/1.1/user_install does not exist. ... My configure line set the prefix like this: ./configure --enable-perl=/product/perl/bin/perl --disable-nls --prefix=/product/gimp I've tried setting the GIMP_HOME environment variable to /product/gimp, and added /product/gimp/lib to my LD_LIBRARY_PATH. Any ideas? Any help appreciated. -- Also, configure ignores the perl executable argument specified in the --enable-perl option (see configure line above, for example), and always looks for "perl5" in the default path. I don't know if this is Irix-specific behaviour, but even if it were, it would be strange because Irix has had a "perl" as well as a "perl5" for some time now. I think the preferred behaviour would be to accept the argument received, if any, and then look for "perl". -- Warren Hedley Department of Engineering Science Auckland University New Zealand
en.gmo bug in localization configure
Hi! The following has happened with all gimps after 1.1.18, even 1.1.20. I have now found the cause. After doing a successful ./configure "make" gives the following: Making all in po make[2]: Entering `/home/winters/gimp-1.1.18/po' make[2]: *** No rule to make target `en.gmo', needed by `all-yes'. Stop. make[2]: Leaving directory `/home/winters/gimp-1.1.18/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/winters/gimp-1.1.18' make: *** [all-recursive-am] Error 2 (error actually taken from Jon Winters post to the list, but mine was identical except for directories names) The reason is something in my system (gnome,enlightenment, or maybe gdm) sets the variable LINGUAS to en . Gimp has nothing in its localization for that so the compilation fails. A check in the configure file for this would be useful. I guess the cleanest would be that if LINGUAS variable is not recognized it should default to english and not give any other problems. In the meantime, maybe adding this to the readme would be useful. I solved it by setting doing "unsetenv LINGUAS" To repeat: setenv LINGUAS (to something not in the .po .gmo files, en) and run ./configure, make Great work! Mayly
more configure errors
Hi there, starting with GIMP 1.1.19, you silently assume that glib.h can be found by using the CFLAGS gnome-config provides. This breaks the test for GTKXmHtml as it is not the case if you've got a local (newer) GLIB/GTK installed separated from GNOME. Fix: Add $GTK_CFLAGS to GTKXMHTML_FLAGS and do the same for *_LIBS. HTH! Tino. -- * LINUX - Where do you want to be tomorrow? *
configure error
Hi, Running the current configure fails for me, as I don't have GtkXMHTML installed. This leaves $HELPBROWSER unset and causes a "test" failure. Keith. Here's a small patch to configure.in. *** configure.in.orig Thu Mar 30 21:28:54 2000 --- configure.inThu Mar 30 23:42:29 2000 *** *** 552,558 dnl Sanity check to make sure the headers are there too and that gnome-config dnl didn't lie to us ! if test -n $HELPBROWSER; then gimp_save_CPPFLAGS="$CPPFLAGS" gimp_save_LDFLAGS="$LDFLAGS" gimp_save_LIBS="$LIBS" --- 552,558 dnl Sanity check to make sure the headers are there too and that gnome-config dnl didn't lie to us ! if test -n "$HELPBROWSER"; then gimp_save_CPPFLAGS="$CPPFLAGS" gimp_save_LDFLAGS="$LDFLAGS" gimp_save_LIBS="$LIBS"
Unable to ./configure
This afternoon I downloaded and attempted to install the latest Gimp. ./configure failed to detect that I am running the latest versiong of gtk and bombed. The instructions given for those who know they have the latest version of gtk were not helpful. I'm still stuck using an ancient buggy version of Gimp. I'm using RedHat Linux version 6.1 and the latest gnome, GTK, etc. rpm -q gtk+ yields this: gtk+-1.2.6-1 Any help is appriciated. It sucks that the Gimp I'm running on my windows machine at work is several releases more current than my Linux box at home. grumble -- Jon Winters visit the Obscura Lounge in OpenVerse http://www.openverse.org/
Re: Unable to ./configure
This afternoon I downloaded and attempted to install the latest Gimp. ./configure failed to detect that I am running the latest versiong of gtk and bombed. The instructions given for those who know they have the latest version of gtk were not helpful. I'm still stuck using an ancient buggy version of Gimp. I'm using RedHat Linux version 6.1 and the latest gnome, GTK, etc. Are you sure you have glib-devel and gtk+-devel installed? Just a quick guess... Salut, Sven
