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
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: 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
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 | |
strange configure errors with perl in 1.1.29
I found some strange errors while configuring Gimp-Perl in 1.1.29. The previous versions worked fine (1.1.25 and 1.1.26 from tarball, 1.1.27 and 1.1.28 patched from previous version) so this looks like a new error. What happened was that perl could not find the required modules (PDL, Perl-Gtk, Parse::RecDescent) although they were installed correctly and were working with all recent versions of the Gimp. After a bit of investigation, I discovered that the perl configuration script was not using the right version of Perl! Instead of taking /Local/bin/perl which is listed first in my path and has all the required modules installed, it was taking /opt/local/perl5/bin/perl which comes later in my path. This older perl executable is also symlinked from /bin/perl and /usr/bin/perl, but all these directories come after /Local/bin. Here is the output from the top-level configure script, which also shows another problem with a missing Makefile in devel-docs/pdb/: [...] creating devel-docs/libgimp/Makefile creating devel-docs/pdb/Makefile Can't open ./devel-docs/pdb/Makefile.in creating data/Makefile creating data/brushes/Makefile [...] creating help/images/Makefile creating config.h invoking perl for configuration... WARNING: unable to use PDL (the perl data language). This means that normal pixel access is non-functional. Unless you plan to use Tile/PixelRgn functions together with PDL, this is harmless. The plug-ins using PDL, however, will NOT WORK and you can NO LONGER install PDL later. You can get PDL from any CPAN mirror. checking for PDL support... no NOTICE: You are using a version of perl older than 5.005. This will slightly reduce the features available to the Gimp-Perl extension. NOTICE: unable to use the Perl-Gtk interface. Many features (like Gimp::Fu) rely on this extension. You can build without it (and many scripts will be disabled or run with reduced functionality only), but it's better to install it (version 0.6123 or higher is required, you can get it from ftp://ftp.gimp.org/pub/gtk/perl/ or any CPAN mirror. NOTICE: Parse::RecDescent not found, scm2perl, the Scheme->Perl translator, will not work. This is normally not a problem, since it is quite unimportant for most people. building embedded perl module... no writing Gimp/Config.pm... ok Checking if your kit is complete... Warning: the following files are missing in your kit: po/Makefile.PL po/update.sh Please inform the author. Warning: prerequisite Gtk 0.5 not found at (eval 4) line 221. Warning: prerequisite PDL 1.99 not found at (eval 4) line 221. Warning: prerequisite Parse::RecDescent 1.6 not found at (eval 4) line 221. Writing Makefile for Gimp::Lib Writing Makefile for Gimp::Net Note (probably harmless): No library found for -lgimp Writing Makefile for Gimp::UI Writing Makefile for Gimp [...] I do not understand why this happened. Going to the perl plug-in directory and typing "make distclean; perl Makefile.PL; make" seemed to solve the problem, but configuring from a freshly extracted tar file did not work. -Raphael P.S.: Thanks to Simon for the splash screen. I will still try to finish and upload mine in case we ever need a 1.1.30.
[garrick@nebula.dsl.speakeasy.net: failure with gimp 1.1.23 (was Re: [Bug #116288] configure failswithgimp 1.1.17)]
This is really something that needs to be fixed in gimp.m4. Gimp
developer folks, could you please check this?
--- Start of forwarded message ---
Date: Mon, 16 Oct 2000 11:06:18 -0700 (PDT)
From: Garrick James <[EMAIL PROTECTED]>
To: Robert L Krawitz <[EMAIL PROTECTED]>
Subject: failure with gimp 1.1.23 (was Re: [Bug #116288] configure fails
withgimp 1.1.17)
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sorry to bug you again about this, but I have found an honest bug in
configure for print-4.0.b[23].
I gave up on gimp 1.1.17 (as you said) and upgraded to gimp 1.1.23 (the
last one to use glib/gtk 1.2.7).
configure still did not work properly. After digging around I found the
following chunk of C code in two places in configure:
#if GIMP_CHECK_VERSION(1,1,20)
GimpPlugInInfo
#else
GPlugInInfo
#endif
PLUG_IN_INFO =
{
NULL, /* init_proc */
NULL, /* quit_proc */
NULL, /* query_proc */
NULL /* run_proc */
};
The problem is that the definitions in question did not change until gimp
1.1.24 (not 1.1.20 as configure is testing for). Gimp 1.1.20 - 1.1.23 all
use GPlugInInfo (I downloaded all the sources and checked). Gimp 1.1.24
was the first to use GimpPlugInInfo. Changing the version check from
1,1,20 to 1,1,24 makes everything work as it should.
After making the change, everything compiled and works wonderfully with
gimp 1.1.23.
If you haven't already, close the bug I opened (#116288) and, if possible,
make the above changes for print-4.0b3.
Thanks for a great printer driver for my old Epson Stylus Color!!
- -Garrick
On Sat, 7 Oct 2000, Robert L Krawitz wrote:
>Date: Fri, 6 Oct 2000 19:43:18 -0700 (PDT)
>From: Garrick James <[EMAIL PROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Thanks for such a prompted response.
>
>But, crap. I'm screwed. I cannot use gimp 1.0, as it doesn't have some
>functionality which I (rather my wife) need.
>
>I really cannot upgrade, as the newer versions of gimp require gtk
>1.2.8 and glib 1.2.8. My linux distribution (Debian potato) includes
>1.2.7 of both libs. After digging through the glib and gtk docs/notes/etc
>it is indicated that 1.2.8 is not binarily backward compatable with 1.2.7
>for both libs. There's no way I'm going to recomile my whole system from
>scratch. :-(
>
> You don't need to. You can have both versions installed concurrently.
>
>Do you have any idea what the two listed args to gimptool do? Can you
>provide me with sample output for both so I can try to hack up the
>configure script for my system?
>
> [2(rlk)||{!690}/mnt1/images]
> $ gimptool --gimpdatadir
> /usr/local/Libraries/share/gimp/1.1
> [2(rlk)||{!691}/mnt1/images]
> $ gimptool --gimpplugindir
> /usr/local/Libraries///gimp/1.1
>
> However, the plugin itself may not compile; I think we blew back
> compatibility a while back, too (although there is back compatibility
> with gimp 1.0).
>
> --
> Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
>
> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
> Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
>
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>
--- End of forwarded message ---
Re: configure, libtool & the install prefix [2]
On 4 Oct, Marco Lamberto wrote: > 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). If you don't want to use RPMs features, why do you want to use it at all? configure;make install is much simpler and cleaner and if you want to package it you have to care about all the shit anyway Please note: RPM is broken by design and you can't use one specfile for several systems because of the differences. Thus I don't see much sense in shipping them. Ok, it's cheap advertising for RedHat but apart from that -- Servus, Daniel
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
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 | |
configure, libtool & the install prefix [2]
May be I've posted a stupid question! ;P
I suppose that now the DESTDIR var should be used instead of prefix and PREFIX
when installing elsewhere, however the gimp.spec.in should be changed and
there are few bugs into the Makefile.in.in into some of the po* dirs.
I've attached a patch for fixing those minor problems. ;)
I haven't fixed yet the GIMP Perl plugins installation, please could anyone fix
it or tell me a workaround?
Happy GIMPing,
Marco
--
//\/\ Marco (LM) Lamberto
e-mail:lm(at)geocities.com (replace '(at)' -> '@')
The Sunny Spot - http://www.geocities.com/marcolamberto/
--- ./gimp-1.1.26/po/Makefile.in.in.origFri Sep 22 21:10:56 2000
+++ ./gimp-1.1.26/po/Makefile.in.in Sun Oct 1 14:49:51 2000
@@ -123,7 +123,7 @@
*) destdir=$(localedir);; \
esac; \
lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
- dir=$$destdir/$$lang/LC_MESSAGES; \
+ dir=$(DESTDIR)$$destdir/$$lang/LC_MESSAGES; \
if test -r "$(MKINSTALLDIRS)"; then \
$(MKINSTALLDIRS) $$dir; \
else \
--- ./gimp-1.1.26/po-libgimp/Makefile.in.in.origSun Oct 1 14:50:57 2000
+++ ./gimp-1.1.26/po-libgimp/Makefile.in.in Sun Oct 1 14:51:12 2000
@@ -123,7 +123,7 @@
*) destdir=$(localedir);; \
esac; \
lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
- dir=$$destdir/$$lang/LC_MESSAGES; \
+ dir=$(DESTDIR)$$destdir/$$lang/LC_MESSAGES; \
if test -r "$(MKINSTALLDIRS)"; then \
$(MKINSTALLDIRS) $$dir; \
else \
--- ./gimp-1.1.26/po-script-fu/Makefile.in.in.orig Sun Jun 25 21:28:30 2000
+++ ./gimp-1.1.26/po-script-fu/Makefile.in.in Sun Oct 1 14:52:53 2000
@@ -130,7 +130,7 @@
*) destdir=$(localedir);; \
esac; \
lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
- dir=$$destdir/$$lang/LC_MESSAGES; \
+ dir=$(DESTDIR)$$destdir/$$lang/LC_MESSAGES; \
if test -r "$(MKINSTALLDIRS)"; then \
$(MKINSTALLDIRS) $$dir; \
else \
--- ./gimp-1.1.26/gimp.spec.in.orig Sat Aug 19 18:08:46 2000
+++ ./gimp-1.1.26/gimp.spec.in Sun Oct 1 14:48:41 2000
@@ -91,7 +91,7 @@
[ -n "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != / ] && rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/%{prefix}/info $RPM_BUILD_ROOT/%{prefix}/include \
$RPM_BUILD_ROOT/%{prefix}/lib $RPM_BUILD_ROOT/%{prefix}/bin
-make prefix=$RPM_BUILD_ROOT/%{prefix} PREFIX=$RPM_BUILD_ROOT/%{prefix} install
+make DESTDIR=$RPM_BUILD_ROOT PREFIX=$RPM_BUILD_ROOT/%{prefix} install
# Strip the executables
strip $RPM_BUILD_ROOT/%{prefix}/bin/gimp
@@ -230,6 +230,10 @@
%files perl -f gimp-perl-files
%changelog
+* Sun Oct 01 2000 Marco Lamberto <[EMAIL PROTECTED]>
+- updated the install section by adding the DESTDIR environment var to
+ "make install"
+
* Fri Apr 14 2000 Matt Wilson <[EMAIL PROTECTED]>
- include subdirs in the help find
- remove gimp-help-files generation
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
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 --with-mp=yes Who wants it?
On Thu, Sep 14, 2000 at 04:30:34PM +, Jay Cox <[EMAIL PROTECTED]> wrote: > 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 built --with-mp=yes since about it was created (but disabled --enable-threads quite quickly ;), and the only problems I do get a *lot* is indeed refresh problems. I can't say I ever get a visible speed improvement (I do have a dual-cpu machine). I'll try without-mp ASAP. > I don't think we should remove MP mode quite yet, but I am rather biased. Well, I originally thought that --enable-threads (a misnomer, as it enabled async io of sorts) would be a very good idea as well. And it still is, but it never ever worked, so it got disabled (or even removed?). So if we can't get it wto work it should be disabled, but I don't think it should be removed, as it did quite good generally. Some profiling would help gimp a lot (in general), so we shouldn't look too much about the actual speed until we optimized the gimp a lot. (Yes, I wanted to do that... if I had time... sorry...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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?
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/
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?
On Wed, Sep 13, 2000 at 07:49:13AM -0400, thus said Garry R. Osgood: > <#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. I used this a while ago, since I got a dual cpu machine. It compiled and seemed to work ok, but I started to getting a lot of "Aiee! We lost a thread!" -messages that eventually caused a crash. It is not stable enough for daily use, thus I dont use it anymore. (just to let you know of how it presently works) Tuomas -- .---> [EMAIL PROTECTED] .|\,/| [EMAIL PROTECTED] <-. +> www.helixcode.com - ()-@@ , tigert.gimp.org <+ `-> art director , `--')/ a gimp artist <---'
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: > > > 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
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: 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
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 | |
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
Fwd: BUG IN CONFIGURE: gettext (Formerly on gimp-user as "Re: 'make' of 1.1.24")
The error in the build was: > > make[2]: Entering directory `/usr/local/gimp-1.1.24/po-plug-ins' > file=./`echo uk | sed 's,.*/,,'`.gmo \ > && rm -f $file && PATH=../src:$PATH no -o $file uk.po > /bin/sh: no: command not found > The error message "/bin/sh: no: command not found" is produced by an error by configure. If the package "gettext" is broken or not installed then "no" gets placed in the makefile - instead of the name and path of gettext. The solution is to install or fix gettext, and for the developers to sort the problem in the configure file. I can't take credit for this info, it's a current topic on the enlightenment list. Jonathan Paton -- __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
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
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
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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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"
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
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. -- Jon Winters visit the Obscura Lounge in OpenVerse http://www.openverse.org/
