GIMP 2.3.4
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
GIMP 2.3.4 | Lance Dockins | 23 Sep 20:57 |
GIMP 2.3.4 | Sven Neumann | 23 Sep 22:30 |
GIMP 2.3.4 | Lance Dockins | 23 Sep 22:40 |
GIMP 2.3.4 | michael chang | 23 Sep 22:51 |
GIMP 2.3.4 | Tor Lillqvist | 23 Sep 23:31 |
GIMP 2.3.4 | Michael Schumacher | 23 Sep 23:43 |
GIMP 2.3.4 | Axel Wernicke | 24 Sep 00:47 |
GIMP 2.3.4 | Michael Schumacher | 24 Sep 13:29 |
GIMP 2.3.4 | Sven Neumann | 25 Sep 12:59 |
GIMP 2.3.4 | michael chang | 24 Sep 18:33 |
GIMP 2.3.4 | Michael Schumacher | 25 Sep 09:35 |
GIMP 2.3.4 | michael chang | 25 Sep 19:41 |
GIMP 2.3.4 | Sven Neumann | 25 Sep 21:12 |
GIMP 2.3.4 | Lance Dockins | 27 Sep 14:59 |
GIMP 2.3.4 | Sven Neumann | 27 Sep 22:55 |
GIMP 2.3.4 | Lance Dockins | 28 Sep 14:56 |
GIMP 2.3.4 | John Cupitt | 28 Sep 16:25 |
GIMP 2.3.4 | Lance Dockins | 28 Sep 16:37 |
GIMP 2.3.4 | John Cupitt | 28 Sep 16:56 |
GIMP 2.3.4 | Michael Schumacher | 28 Sep 19:57 |
GIMP 2.3.4 | Tor Lillqvist | 29 Sep 00:32 |
GIMP 2.3.4 | Carol Spears | 28 Sep 19:22 |
GIMP 2.3.4 | Nathan Summers | 29 Sep 00:27 |
GIMP 2.3.4 | Michael Schumacher | 29 Sep 01:13 |
GIMP 2.3.4 | Tor Lillqvist | 29 Sep 01:28 |
GIMP 2.3.4 | Nathan Summers | 29 Sep 01:33 |
GIMP 2.3.4 | Sven Neumann | 29 Sep 21:07 |
GIMP 2.3.4 | Manish Singh | 30 Sep 02:58 |
GIMP 2.3.4 crash on winxp | Paolo Magnoli | 30 Sep 10:44 |
GIMP 2.3.4 crash on winxp | John Cupitt | 30 Sep 11:18 |
R: GIMP 2.3.4 crash on winxp | Paolo Magnoli | 30 Sep 11:43 |
R: GIMP 2.3.4 crash on winxp | John Cupitt | 30 Sep 12:11 |
GIMP 2.3.4 crash on winxp | Tor Lillqvist | 30 Sep 14:22 |
GIMP 2.3.4 | <pmagnoli@systemevolution.it> | 23 Sep 22:53 |
GIMP 2.3.4 | Lance Dockins | 23 Sep 23:13 |
GIMP 2.3.4 | Sven Neumann | 23 Sep 23:10 |
GIMP 2.3.4 | shaneyfelt@juno.com | 25 Sep 08:53 |
GIMP 2.3.4 | lode leroy | 03 Oct 16:49 |
GIMP 2.3.4 | jernej@ena.si | 03 Oct 18:26 |
GIMP 2.3.4 | Tor Lillqvist | 04 Oct 00:48 |
GIMP 2.3.4 | lode leroy | 04 Oct 10:37 |
GIMP 2.3.4 | Tor Lillqvist | 04 Oct 10:58 |
GIMP 2.3.4 | Lance Dockins | 04 Oct 16:04 |
GIMP 2.3.4 | Carol Spears | 04 Oct 18:58 |
GIMP 2.3.4 | Lance Dockins | 04 Oct 19:50 |
GIMP 2.3.4 | Carol Spears | 04 Oct 20:14 |
GIMP 2.3.4 | michael chang | 05 Oct 02:12 |
GIMP 2.3.4 | Leon Brooks | 05 Oct 03:09 |
GIMP 2.3.4 | Hal V. Engel | 04 Oct 21:11 |
GIMP 2.3.4 | Lance Dockins | 04 Oct 23:28 |
GIMP 2.3.4 | Hal V. Engel | 04 Oct 23:37 |
GIMP 2.3.4 | Leon Brooks | 05 Oct 04:02 |
GIMP 2.3.4 | Sven Neumann | 04 Oct 20:50 |
GIMP 2.3.4 | michael chang | 05 Oct 02:12 |
GIMP 2.3.4 | Leon Brooks | 05 Oct 03:06 |
GIMP 2.3.4 | lode leroy | 05 Oct 17:28 |
GIMP 2.3.4 | Manish Singh | 05 Oct 21:31 |
GIMP 2.3.4 | Michael Schumacher | 04 Oct 18:00 |
GIMP 2.3.4 | Michael Schumacher | 04 Oct 18:11 |
GIMP 2.3.4 | jernej@ena.si | 04 Oct 19:41 |
GIMP 2.3.4
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
GIMP 2.3.4
Hi,
Lance Dockins writes:
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS?
Sven
GIMP 2.3.4
Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the case, is there an easy way to download the source from CVS? Thanks in advance for any feedback you can offer.
Sven Neumann wrote:
Hi,
Lance Dockins writes:
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS?
Sven
GIMP 2.3.4
On 9/23/05, Lance Dockins wrote:
Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I
Solution: Linux/POSIX emulation layer. Cygwin is usually used.
MinGW/MSYS is also workable, IIRC. I've never compiled GIMP on either, though.
could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe
Cygwin or MinGW/MSYS, as I said.
You'll also need the development codes for various graphics libraries, e.g. libpng-dev. These are provided in sepearte packages (e.g. select in the Cygwin Installer) or available by compiling the libraries from source.
I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the
Almost.
case, is there an easy way to download the source from CVS? Thanks in
The cvs tool. ;)
advance for any feedback you can offer.
Sven Neumann wrote:
Hi,
Lance Dockins writes:
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS?
Of course, at the end of the day, I think it'd be nicest if they made an installer for the Windows binaries for the development releases, but I'm quite sure that's probably more work than it's worth.
One of these days, I know I'll get around to compiling GIMP from CVS myself. Just need to clear out some working space first.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
GIMP 2.3.4
Hi,
you can safely follow the instructions at
http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows you just need to
modify the supplied CompileGimp.sh updating the lines listing GTK_PACKAGES
and MINGW_PACKAGES as there are more recent versions avaliable, mine are:
# Names of packages and versions.
GTK_PACKAGES=”glib-2.6.5 glib-dev-2.6.5 gtk+-2.6.8 gtk+-dev-2.6.8
pango-1.8.0 pango-dev-1.8.0 atk-1.9.0 atk-dev-1.9.0″
MINGW_PACKAGES=”libpng-1.2.8-bin libpng-1.2.8-dep libpng-1.2.8-lib jpeg-6b-4-bin jpeg-6b-4-dep jpeg-6b-4-lib tiff-3.7.3-bin tiff-3.7.3-lib freetype-2.1.10-bin freetype-2.1.10-lib zlib-1.2.3-bin zlib-1.2.3-lib libgw32c-0.4-lib libiconv-1.8-1-bin libiconv-1.8-1-lib”
don’t forget to update also GIMP_PACKAGE and GIMP_BASE
also change the final compile command to suit your environment (the prefix):
echo “Building and installing The GimpShop” ./configure –disable-print –disable-python –prefix=/YOURFOLDERHERE && make && make install
Be warned, compilation takes some time … I’ll make GIMP 2.3.3 available on eMule sooner or later. Hope this helps
If the automatic download with wget doesn't work just download the packages
by hand and place them in the temp directory mentioned in the script, then
comment the wget line and rerun it, it will decompress and install them just
fine.
Hope this helps
paolo
Lance Dockins ha scritto
Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the case, is there an easy way to download the source from CVS? Thanks in advance for any feedback you can offer.
Sven Neumann wrote:
Hi,
Lance Dockins writes:
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS?
Sven
GIMP 2.3.4
Hi,
Lance Dockins writes:
Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the case, is there an easy way to download the source from CVS? Thanks in advance for any feedback you can offer.
The extra tools needed to compile from CVS are explained in the file HACKING (as found in the source tree or online at http://developer.gimp.org/HACKING). How to get software from CVS is explained in so many places that it is rather pointless to duplicate that information. gimp.org explains how to get the stable branch at http://www.gimp.org/source/howtos/stable-cvs-get.html. If you don't specify a branch you will get the HEAD branch, which is where the development takes place.
Sven
GIMP 2.3.4
Ahhh... Thanks to all who've responded... I guess I'm getting lost at what packages to download from CVS and in what directories to place them... At present, I've already used Msys to compile GIMP 2.3.3 from a tarball. Since I've never tried compiling from CVS, I wasn't sure IF I would need other software... (Right now I have ActivePerl, Msys, and MinGW per the wiki). More importantly though, I wasn't sure what source to download and to what folders. Can you guys point me in the right direction?
pmagnoli@systemevolution.it wrote:
Hi,
you can safely follow the instructions at http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows you just need to modify the supplied CompileGimp.sh updating the lines listing GTK_PACKAGES and MINGW_PACKAGES as there are more recent versions avaliable, mine are: # Names of packages and versions.
GTK_PACKAGES=”glib-2.6.5 glib-dev-2.6.5 gtk+-2.6.8 gtk+-dev-2.6.8 pango-1.8.0 pango-dev-1.8.0 atk-1.9.0 atk-dev-1.9.0″MINGW_PACKAGES=”libpng-1.2.8-bin libpng-1.2.8-dep libpng-1.2.8-lib jpeg-6b-4-bin jpeg-6b-4-dep jpeg-6b-4-lib tiff-3.7.3-bin tiff-3.7.3-lib freetype-2.1.10-bin freetype-2.1.10-lib zlib-1.2.3-bin zlib-1.2.3-lib libgw32c-0.4-lib libiconv-1.8-1-bin libiconv-1.8-1-lib”
don’t forget to update also GIMP_PACKAGE and GIMP_BASE
also change the final compile command to suit your environment (the prefix):
echo “Building and installing The GimpShop” ./configure –disable-print –disable-python –prefix=/YOURFOLDERHERE && make && make install
Be warned, compilation takes some time … I’ll make GIMP 2.3.3 available on eMule sooner or later. Hope this helps
If the automatic download with wget doesn't work just download the packages by hand and place them in the temp directory mentioned in the script, then comment the wget line and rerun it, it will decompress and install them just fine.
Hope this helpspaolo
Lance Dockins ha scritto
Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the case, is there an easy way to download the source from CVS? Thanks in advance for any feedback you can offer.
Sven Neumann wrote:
Hi,
Lance Dockins writes:
I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release?
Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS?
Sven
GIMP 2.3.4
michael chang writes:
> Solution: Linux/POSIX emulation layer. Cygwin is usually used.
Actually, I think MSYS is more commonly used nowadays, or Microsoft's own Interix. Cygwin is a bit too heavy, and has a tendency of occasionally getting too much in your way. Please note the use of POSIX emulation is for running the build tools (shell, sed, m4, make, awk, expr, perl etc) only, not GIMP itself.
(It presumably is possible to build GIMP to run itself under some POSIX emulation like Cygwin, of course, but then it isn't GIMP on Windows, but really GIMP on yet another Unix (that just happens to be emulated on top of Windows).)
> You'll also need the development codes for various graphics libraries, > e.g. libpng-dev. These are provided in sepearte packages (e.g. select > in the Cygwin Installer)
No. Cygwin's libpng etc development packages are for building Cygwin programs. I don't think Cygwin packages stuff like libpng for cross-development to native Win32 ("mingw"), although they do provide the cross-compiler (gcc -mno-cygwin) and C runtime and Win32 headers and libraries (w32api).
The www.gimp.org/win32/downloads.html page has links to Win32 packages of the required dependencies.
--tml
GIMP 2.3.4
michael chang wrote:
Solution: Linux/POSIX emulation layer. Cygwin is usually used.
MinGW/MSYS is also workable, IIRC. I've never compiled GIMP on either, though.
For GIMP, I'd say that MinGW is preferred - not that there shouldn't any problems with Cygwin, but anyone trying this might be on his own, most other people use MinGw...
Of course, at the end of the day, I think it'd be nicest if they made an installer for the Windows binaries for the development releases, but I'm quite sure that's probably more work than it's worth.
Problem: how to keep each of the places distributing GIMP (some net magazines, other random websites, users) from mistaking it as a new stable release.
Michael
GIMP 2.3.4
Am 23.09.2005 um 23:43 schrieb Michael Schumacher:
michael chang wrote:
Problem: how to keep each of the places distributing GIMP (some net magazines, other random websites, users) from mistaking it as a new stable release.
How about writing it with large red letters on the splash screen - it can't be skipped and is displayed long enough to get the message through :)
lexA
Michael
GIMP 2.3.4
Axel Wernicke wrote:
Am 23.09.2005 um 23:43 schrieb Michael Schumacher:
Problem: how to keep each of the places distributing GIMP (some net magazines, other random websites, users) from mistaking it as a new stable release.
How about writing it with large red letters on the splash screen - it can't be skipped and is displayed long enough to get the message through :)
This is one possible step. Another would be to provide binaries of development releases with a fixed timeout - maybe two months - after which they stop working. This could be configurable at compile time so that it is still possible to build outdated version for reference purposes (or similiar), but it would prevent Joe Average from using or distributing outdated versions.
Michael
GIMP 2.3.4
On 9/23/05, Michael Schumacher wrote:
michael chang wrote:
Solution: Linux/POSIX emulation layer. Cygwin is usually used. MinGW/MSYS is also workable, IIRC. I've never compiled GIMP on either, though.
For GIMP, I'd say that MinGW is preferred - not that there shouldn't any
I prefer MinGW myself, but I believe that if the guy knows how to compile on Linux, it might be more familliar to him to emulate Linux/POSIX on Windows with Cygwin than figure out MSYS/MinGW. But then again, I found it easier to get used to MSYS/MinGW than Cygwin, so... *shrugs*
Of course, at the end of the day, I think it'd be nicest if they made an installer for the Windows binaries for the development releases, but I'm quite sure that's probably more work than it's worth.
Problem: how to keep each of the places distributing GIMP (some net magazines, other random websites, users) from mistaking it as a new stable release.
How about not releasing it on the standard page (e.g. "hiding" it in the developer website somewhere)?
I like the timeout idea too, personally -- POV-Ray (www.povray.org) has monthly timeouts for its various beta versions (and they have a new "beta RC" every month). The problem is that when the timeout dies, then should be a new version; if there isn't one, it's kinda silly to have to re-install the same version to extend the timeout. In that case, determining a timeout would be hard...
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
GIMP 2.3.4
It's easier on everybody if you just modify the splash screen to have a message to the effect of "PRERELEASE VERSION INTENDED FOR DEVELOPMENT TESTING ONLY" rather than forcing people to one day have to do extra work because of someone's arbitrary timeout policy. The message could even tell where to download the production version, or have a button to update it. _-Ted
GIMP 2.3.4
michael chang wrote:
On 9/23/05, Michael Schumacher wrote:
michael chang wrote:
The problem is that when the timeout dies, then should be a new version; if there isn't one, it's kinda silly to have to re-install the same version to extend the timeout.
Reinstalling the same version wouldn't help, I'm talking about a hard timeout there - created when the release tarball is made, for example, and set to e.g. 60 or 90 days into the future.
In that case, determining a timeout would be hard...
Not really. Running development releases is only useful up to a certain time anyway - once current CVS has advanced considerably, there is not much to be gained from using an outdated one. Also, this should encourage people to keep the latest stable release installed - after all, this one will not time out.
And finally, if anyone insists on using a development release longer than the timeout lets him, he can alwyys use the source and disable the timeout at compile time - and we can assume that if someone pops up with an outdated release he know what he's doing.
Michael
GIMP 2.3.4
Hi,
Axel Wernicke writes:
How about writing it with large red letters on the splash screen - it can't be skipped and is displayed long enough to get the message through :)
Of course the splash screen can be skipped. AFAIK many distributons configure GIMP to not show a splash screen. Since GIMP implements startup notification, that's a very reasonable thing to do.
Sven
GIMP 2.3.4
On 9/25/05, Michael Schumacher wrote:
michael chang wrote:
On 9/23/05, Michael Schumacher wrote:
michael chang wrote:
The problem is that when the timeout dies, then should be a new version; if there isn't one, it's kinda silly to have to re-install the same version to extend the timeout.
Reinstalling the same version wouldn't help, I'm talking about a hard timeout there - created when the release tarball is made, for example, and set to e.g. 60 or 90 days into the future.
What I mean is lets say the software times out after 70 days the RC/beta is made. That means that there has to be a new RC/beta after 70 days, or otherwise no one can use it post those 70 days. If there isn't, then someone might just rebuild the current RC for another 70 days, which is pointless.
E.g. if there was a 2.3.5 today, and it expires in 60 days. So that means 2.3.6 has to be released within 60 days. How do we know 2.3.6 will be ready in 60 days?
If you want to force yourself on such a release cycle, by all means, but last I checked, GIMP doesn't used fixed release cycles. I could be wrong though; I'm not a GIMP developer. I mean, it's not like fixed release cycles are all that bad of a thing. Then again, you might want to give yourself some leeway (e.g. trying to release a version of GIMP 15 days before the last RC/beta expired or something; that way delays can be absorbed into the 15 days that remain from the last RC/beta/devel release).
In that case, determining a timeout would be hard...
Not really. Running development releases is only useful up to a certain time anyway - once current CVS has advanced considerably, there is not much to be gained from using an outdated one. Also, this should encourage people to keep the latest stable release installed - after all, this one will not time out.
Well, that's very true. I believe the 2.2.8 version of gimp is really a 2.2.7+cvssomething on Debian - and those are offical packages.
And finally, if anyone insists on using a development release longer than the timeout lets him, he can alwyys use the source and disable the timeout at compile time - and we can assume that if someone pops up with an outdated release he know what he's doing.
True.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
GIMP 2.3.4
Hi,
Michael Schumacher writes:
Reinstalling the same version wouldn't help, I'm talking about a hard timeout there - created when the release tarball is made, for example, and set to e.g. 60 or 90 days into the future.
What's all this fuss? There is absolutely no reason why we should cripple any GIMP release, development version or not, by doing such silly things. This is Free Software. We are distributing it as source code. If someone wants to build binaries and distribute them, so be it. You might not have noticed yet, but binary distribution of the GIMP 2.3 series is not in any way discouraged. Of course we appreciate if pacakagers make it clear that they are distributing an unfinished development release but that's something we can only ask for.
Sven
GIMP 2.3.4
I compiled GIMP 2.3.4 from tarball the other day and I've noticed a few things.
1) The last 2 times I've compiled GIMP, I've found my installation missing some key libraries at the end of the build. Is this normal? (Missing libraries differed each time) To fix it I pulled libraries from my stable GIMP 2.2 installation and that seems to work but some odd things occur in the build that I wouldn't expect - even of a development release.
2) One of those odd things is that the entire layer dialog is non-responsive. No lock ups or anything, it just sits there, does nothing (even when layers are created, etc), and doesn't accept commands. Is this to be expected in the 2.3.4 release or should I expect that something else is wrong.
Here are my system specs
Windows XP SP2, GTK+ 2.6.9
MinGW, MSys, ActivePerl
I built GIMP 2.3.4 with Glib 2.8.0 and GTK+ 2.6.9. I also used atk 1.9.0 and pango 1.8.2
The other dependencies (for various plugins) were the latest stable versions that I could find. Any ideas what might cause this type of behavior?
Sven Neumann wrote:
Hi,
Michael Schumacher writes:
Reinstalling the same version wouldn't help, I'm talking about a hard timeout there - created when the release tarball is made, for example, and set to e.g. 60 or 90 days into the future.
What's all this fuss? There is absolutely no reason why we should cripple any GIMP release, development version or not, by doing such silly things. This is Free Software. We are distributing it as source code. If someone wants to build binaries and distribute them, so be it. You might not have noticed yet, but binary distribution of the GIMP 2.3 series is not in any way discouraged. Of course we appreciate if pacakagers make it clear that they are distributing an unfinished development release but that's something we can only ask for.
Sven
GIMP 2.3.4
Hi,
Lance Dockins writes:
I compiled GIMP 2.3.4 from tarball the other day and I've noticed a few things.
1) The last 2 times I've compiled GIMP, I've found my installation missing some key libraries at the end of the build. Is this normal? (Missing libraries differed each time) To fix it I pulled libraries from my stable GIMP 2.2 installation and that seems to work but some odd things occur in the build that I wouldn't expect - even of a development release.
You did what??? There is really no point in doing such things unless you know very well what you are doing. If you have problems to compile GIMP, ask. And if you ask, please describe your problems in detail. I have left my crystal ball at home today so I really can't figure out what "some missing key libraries at the end of the build" are.
Sven
GIMP 2.3.4
Sven Neumann wrote:
Hi,
Lance Dockins writes:
I compiled GIMP 2.3.4 from tarball the other day and I've noticed a few things.
1) The last 2 times I've compiled GIMP, I've found my installation missing some key libraries at the end of the build. Is this normal? (Missing libraries differed each time) To fix it I pulled libraries from my stable GIMP 2.2 installation and that seems to work but some odd things occur in the build that I wouldn't expect - even of a development release.
You did what??? There is really no point in doing such things unless you know very well what you are doing. If you have problems to compile GIMP, ask.
Sven,
That's what I was doing with my former e-mail. I was advised to
take the missing DLL's from my stable GIMP 2.2 to fill the gap for the
missing DLL's in my fresh compilation of GIMP 2.3. If you're wondering
where I got the advice, I got it from another Windows user who was
compiling GIMP 2.3.3 on GUG. Honestly, I've been able to compile GIMP
twice now, but both times I've wound up short a handful of DLL's in my
bin folder. Since I don't know what DLL's I should have at the end of
compile time, I just guessed and brought over all the missing DLL's as
compared with my GIMP 2.2 build.
And if you ask, please describe your problems in detail. I have left my crystal ball at home today so I really can't figure out what "some missing key libraries at the end of the build" are.
I was asking more generic questions because I was looking for more generic answers. I just wanted to know if missing DLL's was a normal scenario in Win32 environments. Since you clearly know that it's not, you've jumped ahead of me to asking which DLL's were missing. Since I don't know (I didn't write them all down) I'll have to tell you next time I compile. Instead, I offered all the information I had. As far as your "crystal ball" comment, I'd say that was a bit uncalled for. You could have just as easily asked for more information without being biting and sarcastic. You, Sven, of all people should know that flipant biting sarcasm is a great way to discourage people from taking up GIMP or otherwise contributing to it.
What if someone considering the possibility of contributing to GIMP read that post? They probably would think twice at that point for fear of being publicly humiliated for asking a question. Don't get me wrong, I greatly respect your contributions to GIMP and I'm sure it's frustrating answering all of these types of questions. In fact, I know so. My greatest strength is customer service, sales, and otherwise dealing with people so I know how difficult it can be. Let me just put it this way. The ONLY reason people are using or contributing to GIMP is because they have problems. Specifically, they have a need for an image design program that's both powerful and inexpensive and GIMP meets that need. I'm having COMPILE problems WITH GIMP. There's really no difference. People use software, ask questions, etc because they have problems. How you handle those problems WILL determine the success of the project - particularly if you have such an influential position with the project.
At this point, I'd like a little help or direction about compiling GIMP in a Win32 environment with MinGW, MSys, and ActivePerl. For that matter, I'd like to be able to compile from CVS so I need to know how to get my MSys/MinGW setup to recognize the other software requirements (autoconf, libtool, automake, etc.) If anyone can assist with that, I'd be greatful.
Lance
GIMP 2.3.4
On 9/28/05, Lance Dockins wrote:
At this point, I'd like a little help or direction about compiling GIMP in a Win32 environment with MinGW, MSys, and ActivePerl.
It's not GIMP, but I wrote a HOWTO a couple of days ago for building my gtk+ app under mingw:
http://wiki.vips.ecs.soton.ac.uk/bin/view/Main/VipsMingw
For GIMP, don't install fftw. You'll need to install some other libraries too, http://gimp.org/source has a list. I really wouldn't carelessly copy DLLs over from previous versions, I think you're sure to find yourself in a very bad, mysterious place.
That should be enough to be able to build from a distribution tarball ... if you need to build from CVS, it'll be quite a bit more difficult since you'll need to set up all the auto tools stuff as well.
I'm not a windows person so I probably made it more difficult than it needs to be. But I did end up with a binary that seems stable.
John
GIMP 2.3.4
Thanks John. This should help tremendously. Just two other questions then...
1) Is there a way to get python to work on Windows AND is it even
necessary to build GIMP?
2) Where do I install/unzip the all the auto tools? Should I just unzip
them to a location in MinGW and use the export command to include those
directories? I'm assuming that I don't need a special Win32 build of
these tools so I've just downloaded them from their respective
locations. If I'm wrong about this, please let me know so I can get the
right copies. Thanks.
Lance
John Cupitt wrote:
On 9/28/05, Lance Dockins wrote:
At this point, I'd like a little help or direction about compiling GIMP in a Win32 environment with MinGW, MSys, and ActivePerl.
It's not GIMP, but I wrote a HOWTO a couple of days ago for building my gtk+ app under mingw:
http://wiki.vips.ecs.soton.ac.uk/bin/view/Main/VipsMingw
For GIMP, don't install fftw. You'll need to install some other libraries too, http://gimp.org/source has a list. I really wouldn't carelessly copy DLLs over from previous versions, I think you're sure to find yourself in a very bad, mysterious place.
That should be enough to be able to build from a distribution tarball ... if you need to build from CVS, it'll be quite a bit more difficult since you'll need to set up all the auto tools stuff as well.
I'm not a windows person so I probably made it more difficult than it needs to be. But I did end up with a binary that seems stable.
John
GIMP 2.3.4
Hi Lance,
On 9/28/05, Lance Dockins wrote:
1) Is there a way to get python to work on Windows AND is it even necessary to build GIMP?
Yes, I'm sure Python does build on win, but I've not tried. Some gimp plugins use it, so you probably need to spend some time experimenting (unless google turns up a handy howto).
2) Where do I install/unzip the all the auto tools? Should I just unzip them to a location in MinGW and use the export command to include those directories? I'm assuming that I don't need a special Win32 build of these tools so I've just downloaded them from their respective locations. If I'm wrong about this, please let me know so I can get the right copies.
I think msys DTK includes them already. Try "ls /usr/bin/*auto*" and you'll (probably) see stuff. But I don't know if they include the versions that GIMP needs, so you might need to uninstall them and build your own. You'll also need intltoolize I think, and maybe some other stuff.
I'd install everything that wasn't an official mingw or msys package to /usr/local/ to make it easy to wipe if something goes wrong.
(I don't know if this is an option for you, and I know how annoying being told "install linux! problem solved!" is, but building under linux really is 100x easier than mingw. You could put something like Ubuntu on a spare partition in 15 minutes, and have a working gimp-from-cvs build not long after that)
John
GIMP 2.3.4
On Wed, Sep 28, 2005 at 07:56:12AM -0500, Lance Dockins wrote:
What if someone considering the possibility of contributing to GIMP read that post? They probably would think twice at that point for fear of being publicly humiliated for asking a question. Don't get me wrong, I greatly respect your contributions to GIMP and I'm sure it's frustrating answering all of these types of questions. In fact, I know so. My greatest strength is customer service, sales, and otherwise dealing with people so I know how difficult it can be. Let me just put it this way. The ONLY reason people are using or contributing to GIMP is because they have problems. Specifically, they have a need for an image design program that's both powerful and inexpensive and GIMP meets that need. I'm having COMPILE problems WITH GIMP. There's really no difference. People use software, ask questions, etc because they have problems. How you handle those problems WILL determine the success of the project - particularly if you have such an influential position with the project.
do not count on the user base being only as you defined it here.
if you do not want sarcasm or even honest requests for good development style, please post these questions on either the gimp user list or the gimp on windows user list.
the project historically does not want the type of help you described. only if you believe everything that you read is this not still the case.
carol
GIMP 2.3.4
Lance Dockins wrote:
1) Is there a way to get python to work on Windows AND is it even necessary to build GIMP?
Get it from http://www.python.org It is not neccessary to build GIMP, but neccessary for the PyGimp modules and thius Python support in GIMP.
2) Where do I install/unzip the all the auto tools? Should I just unzip them to a location in MinGW and use the export command to include those directories? I'm assuming that I don't need a special Win32 build of these tools so I've just downloaded them from their respective locations. If I'm wrong about this, please let me know so I can get the right copies. Thanks.
They are part of a MinGw package (IIRC the DTK, as mentioned in another mail in this thread). There are also updates available from http://www.mingw.org. But it is also rather easy (and a good test for your build environment) to build them yourself.
P.S. Please quote properly: only cite parts of a mail that you're referring to, and don't reply above the quoted text. Thank you.
HTH, Michael
GIMP 2.3.4
On 9/28/05, Carol Spears wrote:
On Wed, Sep 28, 2005 at 07:56:12AM -0500, Lance Dockins wrote: do not count on the user base being only as you defined it here.
if you do not want sarcasm or even honest requests for good development style, please post these questions on either the gimp user list or the gimp on windows user list.
There is no longer a gimp on windows mailing list, and this isn't a user list question.
the project historically does not want the type of help you described. only if you believe everything that you read is this not still the case.
What? "Customer service" is exactly the type of thing that we need help with.
Rockwalrus
GIMP 2.3.4
Lance Dockins writes:
> 1) Is there a way to get python to work on Windows
Yes. Personally I have so far not really been interested in Python and haven't attempted to build the Python scripting support. But others have it working.
> AND is it even necessary to build GIMP?
No.
> 2) Where do I install/unzip the all the auto tools? Should I just unzip > them to a location in MinGW and use the export command to include those > directories? I'm assuming that I don't need a special Win32 build of > these tools so I've just downloaded them from their respective > locations.
Hmm, you downloaded the auto* sources, or ready-built packages (from where?)? Anyway, you can install them (after building them) anywhere, as long as the executable commands are found in PATH. GIMP HEAD requires newer autotools than what's in the MSYS-DTK package, unfortunately, so I guess you really need to build them yourself. (I don't recall which one of the autotools it is that's too old in MSYS. Probably automake?)
--tml
GIMP 2.3.4
Nathan Summers wrote:
On 9/28/05, Carol Spears wrote:
if you do not want sarcasm or even honest requests for good development style, please post these questions on either the gimp user list or the gimp on windows user list.
There is no longer a gimp on windows mailing list,
Well, for a list that doesn't exist it is pretty active... http://groups.yahoo.com/group/gimpwin-users/
HTH, Michael
GIMP 2.3.4
> > There is no longer a gimp on windows mailing list,
> Well, for a list that doesn't exist it is pretty active... > http://groups.yahoo.com/group/gimpwin-users/
I guess rockwalrus meant there is no *developer-oriented* Windows-specific GIMP (or GTK+) list. That's true.
--tml
GIMP 2.3.4
On 9/28/05, Michael Schumacher wrote:
Nathan Summers wrote:
There is no longer a gimp on windows mailing list,
Well, for a list that doesn't exist it is pretty active... http://groups.yahoo.com/group/gimpwin-users/
That is not the list that no longer exists. :)
Rockwalrus
GIMP 2.3.4
Hi,
Lance Dockins writes:
I was asking more generic questions because I was looking for more generic answers. I just wanted to know if missing DLL's was a normal scenario in Win32 environments. Since you clearly know that it's not, you've jumped ahead of me to asking which DLL's were missing. Since I don't know (I didn't write them all down) I'll have to tell you next time I compile. Instead, I offered all the information I had. As far as your "crystal ball" comment, I'd say that was a bit uncalled for. You could have just as easily asked for more information without being biting and sarcastic. You, Sven, of all people should know that flipant biting sarcasm is a great way to discourage people from taking up GIMP or otherwise contributing to it.
I didn't mean to be sarcastic nor did I try to humiliate anyone. Sorry if you misunderstood my attempt to help you. Next time I will add more sugar when replying to your mails.
Sven
GIMP 2.3.4
On Wed, Sep 28, 2005 at 07:56:12AM -0500, Lance Dockins wrote:
Sven Neumann wrote:
And if you ask, please describe your problems in detail. I have left my crystal ball at home today so I really can't figure out what "some missing key libraries at the end of the build" are.
I was asking more generic questions because I was looking for more generic answers. I just wanted to know if missing DLL's was a normal scenario in Win32 environments. Since you clearly know that it's not, you've jumped ahead of me to asking which DLL's were missing. Since I don't know (I didn't write them all down) I'll have to tell you next time I compile. Instead, I offered all the information I had. As far as your "crystal ball" comment, I'd say that was a bit uncalled for. You could have just as easily asked for more information without being biting and sarcastic. You, Sven, of all people should know that flipant biting sarcasm is a great way to discourage people from taking up GIMP or otherwise contributing to it.
What if someone considering the possibility of contributing to GIMP read that post? They probably would think twice at that point for fear of being publicly humiliated for asking a question. Don't get me wrong, I greatly respect your contributions to GIMP and I'm sure it's frustrating answering all of these types of questions. In fact, I know so. My greatest strength is customer service, sales, and otherwise dealing with people so I know how difficult it can be. Let me just put it this way. The ONLY reason people are using or contributing to GIMP is because they have problems. Specifically, they have a need for an image design program that's both powerful and inexpensive and GIMP meets that need. I'm having COMPILE problems WITH GIMP. There's really no difference. People use software, ask questions, etc because they have problems. How you handle those problems WILL determine the success of the project - particularly if you have such an influential position with the project.
Do you think an open source project is better served by having primary developers handhold everyone that comes along through basic problem solving skills, or using that time to implement new features or fix bugs?
Keeping track of what you did is a rather basic step when diagnosing problems with software. There is a certain comptency level assumed when you try to build GIMP. You didn't live up to it, so don't whine about the resultant response (which really wasn't that bad, although terse).
It's also pretty rude to make blanket statements about the motivations of contributors. You don't speak for everyone.
-Yosh
GIMP 2.3.4 crash on winxp
Hi, I just compiled Gimp 2.3.4 on winxp mingw but when I try to run it I get a windows with this error:
"Pango-ERROR**: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting ..."
then it closes down.
My GTK libs are:
glib-2.8.2 glib-dev-2.8.2 gtk+-2.8.4 gtk+-dev-2.8.4 pango-1.10.0
pango-dev-1.10.0 atk-1.10.1 atk-dev-1.10.1 cairo-1.0.0 cairo-dev-1.0.0
And other mingw packages are: libpng-1.2.8-bin libpng-1.2.8-dep libpng-1.2.8-lib jpeg-6b-4-bin jpeg-6b-4-dep jpeg-6b-4-lib tiff-3.7.2-bin tiff-3.7.2-lib freetype-2.1.8-bin freetype-2.1.8-lib zlib-1.2.2-bin zlib-1.2.2-lib libgw32c-0.4-lib libiconv-1.8-1-bin libiconv-1.8-1-lib
Hope you'll find a way to solve this. Thanks in advance
paolo
GIMP 2.3.4 crash on winxp
On 9/30/05, Paolo Magnoli wrote:
Hi, I just compiled Gimp 2.3.4 on winxp mingw but when I try to run it I get a windows with this error:
"Pango-ERROR**: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting ..."
then it closes down. My GTK libs are:
glib-2.8.2 glib-dev-2.8.2 gtk+-2.8.4 gtk+-dev-2.8.4 pango-1.10.0 pango-dev-1.10.0 atk-1.10.1 atk-dev-1.10.1 cairo-1.0.0 cairo-dev-1.0.0
You pango and atk seem very old, but your glib and gtk seem too new. I'd try again with the packages on Tor's download page:
http://www.gimp.org/~tml/gimp/win32/downloads.html
John
R: GIMP 2.3.4 crash on winxp
Sorry but my pango is pango-1.10.0 when Thor's one is pango-1.8.2, so mine
should be more recent.
Regards
paolo
-----Messaggio originale-----
Da: John Cupitt [mailto:jcupitt@gmail.com] Inviato: venerdì 30 settembre 2005 11.18 A: Paolo Magnoli
Cc: GIMPDev
Oggetto: Re: [Gimp-developer] GIMP 2.3.4 crash on winxpOn 9/30/05, Paolo Magnoli wrote:
Hi, I just compiled Gimp 2.3.4 on winxp mingw but when I try to
run it I get
a windows with this error:
"Pango-ERROR**: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting ..."
then it closes down. My GTK libs are:
glib-2.8.2 glib-dev-2.8.2 gtk+-2.8.4 gtk+-dev-2.8.4 pango-1.10.0 pango-dev-1.10.0 atk-1.10.1 atk-dev-1.10.1 cairo-1.0.0 cairo-dev-1.0.0You pango and atk seem very old, but your glib and gtk seem too new. I'd try again with the packages on Tor's download page:
http://www.gimp.org/~tml/gimp/win32/downloads.html
John
R: GIMP 2.3.4 crash on winxp
On 9/30/05, Paolo Magnoli wrote:
Sorry but my pango is pango-1.10.0 when Thor's one is pango-1.8.2, so mine should be more recent.
D'oh! Sorry. So it sounds like a pango fonts problem. Do any of the pango examples work?
GIMP 2.3.4 crash on winxp
John Cupitt writes:
> > glib-2.8.2 glib-dev-2.8.2 gtk+-2.8.4 gtk+-dev-2.8.4 pango-1.10.0
> > pango-dev-1.10.0 atk-1.10.1 atk-dev-1.10.1 cairo-1.0.0 cairo-dev-1.0.0
> You pango and atk seem very old, but your glib and gtk seem too new.
No, atk 1.10.1 and Pango 1.10.0 are quite new, the latest versions. (Actually, for performance reasons, one should make sure to use the latest pango 1.10.0 snapshot (20050922) from the ftp.gtk.org site.) (GTK+ 2.8 won't even work with any older Pango.) They are available from ftp.gtk.org but not really "advertised" yet on the GTK+ for Win32 download page on the GIMP site.
Sigh, I had hoped that the infamous "shape.c: line 75" assertion failure would have been a thing of the past with GTK+ 2.8 and Pango 1.10. But apparently not. Try the usual stuff, mainly try without the ms-windows theme ("wimp"). (Edit the etc/gtk-2.0/gtkrc file.) Or check what your default font in the Display Properties is, try changing that to for instance Arial.
--tml
GIMP 2.3.4
I also noticed the missing DLL's while compiling gimp with MSYS/MinGW
In fact, what happens is that when linking with ZLIB.DLL, the exe expects ZLIB-1.DLL instead of ZLIB1.DLL. (or vice-versa). I copied the names that were closest to the ones expected...
48793 Aug 24 2002 regex.dll
48793 Aug 24 2002 libregex.dll
70656 Dec 13 2003 zlib1.dll
70656 Dec 13 2003 zlib-1.dll
460800 May 9 2004 freetype6.dll
460800 May 9 2004 freetype-6.dll
203264 Dec 4 2004 libpng13.dll
203264 Dec 4 2004 libpng.dll
127488 May 15 14:08 jpeg62.dll
127488 May 15 14:08 jpeg-62.dll
So the "missing dll's" in question are a build-environment issue, and not a gimp-compilation issue...
So the suggestion to copy dll's from the previous stable version wasn't that bad a suggestion either...
it would have prevented a lot of confusion if the names of the dll's were listed ...
of course it would be nice to have those resolved too...
GIMP 2.3.4
On Monday, October 3, 2005, 16:49:59, lode leroy wrote:
So the "missing dll's" in question are a build-environment issue, and not a gimp-compilation issue...
Just make sure you use the correct import libraries.
GIMP 2.3.4
lode leroy writes:
> In fact, what happens is that when linking with ZLIB.DLL,
> the exe expects ZLIB-1.DLL instead of ZLIB1.DLL. (or vice-versa).
The official zlib dll is called zlib1.dll. Any other name means it is not official. "Official" as in directly from real maintainer of zlib. As the actual maintainer of zlib distributes Win32 zlib binaries, I fail to see any reason why one would want to use anybody else's version. I have only zlib1.dll on my system.
Don't know about the other examples you list. Presumably caused by confusion at the "gnuwin32" (not related to GNU) site. You really should try to find a coherent set of interdependent packages. Is it so that the GTK+ binaries I depend on differently named DLLs than what gnuwin32 currently distribute? Argh, I just hate that kind of instability.
--tml
GIMP 2.3.4
From: Tor Lillqvist
To: "lode leroy"
CC: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP 2.3.4 Date: Tue, 4 Oct 2005 01:48:10 +0300lode leroy writes: > In fact, what happens is that when linking with ZLIB.DLL, > the exe expects ZLIB-1.DLL instead of ZLIB1.DLL. (or vice-versa).
The official zlib dll is called zlib1.dll. Any other name means it is not official. "Official" as in directly from real maintainer of zlib. As the actual maintainer of zlib distributes Win32 zlib binaries, I fail to see any reason why one would want to use anybody else's version. I have only zlib1.dll on my system.
I agree with you Tor, but as the original poster wrote, it is very difficult to set up a build enviroment with everything correct to compile gimp (or other gtk based software for that matter)
Libraries and dependencies are changing, and the available binaries
are sometimes not correctly packaged with missing or incorrect .m4 or .pc
files
(especially the fontconfig and freefont,i.e. the one's you don't distribute
:-)
The thing is that for compiling gimp from cvs, you need quite some expertise in the autotools, libtool, aclocal, pkg-config etc to fix those not-100%-working-together- distributed binaries...
Would it be feasible to create a big zip-file that contains everything for
gimp
for download?
--tml
GIMP 2.3.4
lode leroy writes:
> The thing is that for compiling gimp from cvs, you need quite some expertise
> in the autotools, libtool, aclocal, pkg-config etc to fix those
> not-100%-working-together- distributed binaries...
> Would it be feasible to create a big zip-file that contains everything for > gimp for download?
It would be possible, but wouldn't such a zipfile just create open up the possibility for even more confusion when there would then be yet another distribution of these libs? (A long time ago I *did* distribute self-built jpeg, tiff, zlib and whatnot, but stopped doing that as there were other distributions, too, that were just as good, or even more directly from the source, like zlib.)
--tml
GIMP 2.3.4
Tor Lillqvist wrote:
It would be possible, but wouldn't such a zipfile just create open up the possibility for even more confusion when there would then be yet another distribution of these libs?
Tor,
You're right. Alternative packages always open up the possibility
for more confusion when there are already so many Win32 binaries.
Honestly though, I'd be willing to accept such a potential for confusion
to find a packaged set of reliable Win32 binaries that would work with
each other in a MinGW/Msys environment and provide a means of compiling
GIMP from CVS/Tarball on Win32 without having to spend hours
researching, compiling, and downloading to get the environment setup
correctly. For that matter, when I'm looking for reliable Win32
binaries, your packages are amongst the top 3 I would trust. Of course,
finding such a zip anywhere would nearly be a godsend regardless of who
compiled and packaged the binaries just because of the fact that it's so
hard to find all the binaries you need in a Win32 environment in the
first place.
I should also clarify that I have considered switching to Linux to make this easier, but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world. My guess is that's the case for many Windows users who would like to be able to compile from tarball/CVS without such hassles as we've described here. Grant that I don't speak for everyone using Win32, but I'd imagine you'd see a positive reception from such an endeavor from more than one Win32 user.
GIMP 2.3.4
Von: "lode leroy"
From: Tor Lillqvist
To: "lode leroy"
CC: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP 2.3.4 Date: Tue, 4 Oct 2005 01:48:10 +0300lode leroy writes: > In fact, what happens is that when linking with ZLIB.DLL, > the exe expects ZLIB-1.DLL instead of ZLIB1.DLL. (or vice-versa).
The official zlib dll is called zlib1.dll. Any other name means it is not official. "Official" as in directly from real maintainer of zlib. As the actual maintainer of zlib distributes Win32 zlib binaries, I fail to see any reason why one would want to use anybody else's version. I have only zlib1.dll on my system.
I agree with you Tor, but as the original poster wrote, it is very difficult to set up a build enviroment with everything correct to compile gimp (or other gtk based software for that matter)
Libraries and dependencies are changing, and the available binaries are sometimes not correctly packaged with missing or incorrect .m4 or .pc files
(especially the fontconfig and freefont,i.e. the one's you don't distribute
:-)
We should then let the packagers know... maybe they just don't get the right hints? For example, gnuwin32 had these naming problems, and there is a way to report bugs. I recall that the .a files of libxml2 were not usable with the MinGW linker, this could be reported also...
HTH, Michael
GIMP 2.3.4
Von: jernej@ena.si
On Monday, October 3, 2005, 16:49:59, lode leroy wrote:
So the "missing dll's" in question are a build-environment issue, and not a gimp-compilation issue...
Just make sure you use the correct import libraries.
It is also possible to create them yourself, from the DLL files. The MinGW docs contain a section about this (using pexports and dlltool, IIRC).
HTH, Michael
GIMP 2.3.4
On Tue, Oct 04, 2005 at 09:04:42AM -0500, Lance Dockins wrote:
I should also clarify that I have considered switching to Linux to make this easier, but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world. My guess is that's the case for many Windows users who would like to be able to compile from tarball/CVS without such hassles as we've described here. Grant that I don't speak for everyone using Win32, but I'd imagine you'd see a positive reception from such an endeavor from more than one Win32 user.
this is so interesting. Win32 has succeeded in making linux expensive.
you are asking that the Win32 environment not work the way it was designed to work -- at least i think this is what you are saying.
i am very impressed that it was able to make free software expensive, this is a simply amazing accomplishment!
carol
GIMP 2.3.4
On Tuesday, October 4, 2005, 18:11:36, Michael Schumacher wrote:
It is also possible to create them yourself, from the DLL files. The MinGW docs contain a section about this (using pexports and dlltool, IIRC).
Didn't you write instructions for this in the wiki?
GIMP 2.3.4
this is so interesting. Win32 has succeeded in making linux expensive.
you are asking that the Win32 environment not work the way it was designed to work -- at least i think this is what you are saying.
i am very impressed that it was able to make free software expensive, this is a simply amazing accomplishment!
Carol,
Where in my e-mail did your read that *Linux *was going to cost me
money? Read that sentence again. Or, better yet, I'll quote it. "I
should also clarify that I have considered switching to Linux to make
this easier, *but I just don't have the time, money, and hardware to do
so without destroying the Win32 environment I'm required to use in the
professional world.*" Did I say that the money, time, and hardware I
was going to invest was going to be invested in buying Linux or did I
just say that I would have to invest money, time, and hardware into a
Linux setup? Here's a few things that cost money that fit perfectly into
that sentence.
* Time
* A spare hard drive
* A reliable partition manager (instead of a drive)
* Perhaps an alternate computer entirely
* Potential other hardware for those components that Linux drivers
don't function well on.
Before I sign off on this, let me quote the second half of that sentence again. *"*But I just don't have the time, money, and hardware to do so *without destroying the Win32 environment I'm required to use in the professional world.*" So that pretty much eliminates installing over top of my current OS.
Lance
GIMP 2.3.4
yeah, i read something that seemed as if it was too expensive to use free software and a sane build environment. i have been wrong before.
carol
GIMP 2.3.4
Hi,
Lance Dockins writes:
I should also clarify that I have considered switching to Linux to make this easier, but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world. My guess is that's the case for many Windows users who would like to be able to compile from tarball/CVS without such hassles as we've described here. Grant that I don't speak for everyone using Win32, but I'd imagine you'd see a positive reception from such an endeavor from more than one Win32 user.
Why would users want to compile development snapshots? I see the point in making it easier for people to develop on Windows and I would also like to see some features being tested earlier on all platforms, but still fail to see why users would want to compile a 2.3.x release. They can use the binary packages.
Sven
GIMP 2.3.4
On Tuesday 04 October 2005 09:58 am, Carol Spears wrote:
On Tue, Oct 04, 2005 at 09:04:42AM -0500, Lance Dockins wrote:
I should also clarify that I have considered switching to Linux to make this easier, but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world. My guess is that's the case for many Windows users who would like to be able to compile from tarball/CVS without such hassles as we've described here. Grant that I don't speak for everyone using Win32, but I'd imagine you'd see a positive reception from such an endeavor from more than one Win32 user.
this is so interesting. Win32 has succeeded in making linux expensive.
you are asking that the Win32 environment not work the way it was designed to work -- at least i think this is what you are saying.
i am very impressed that it was able to make free software expensive, this is a simply amazing accomplishment!
carol
Carol was a little over the top but is making a valid point. Windows and Linux can live on the same machine with no problems. So you do not have to "destroy the Wind32 environment". Many of the folks on this list, myself included, have both Linux and Windows running on the machines they use on a daily basis. If all you need is enough of a Linux installation to get GIMP to build and to test GIMP then the amount of diskspace needed to do this is fairly small and you can free up a partition on your existing hard drive(s) to do this. In addition, most Linux distros are free. So this clearly does not take any money or new/additional hardware.
The real issue is time. Which is a valid concern but it might actually take less time and effort to get a working Linux environment than to mess around getting Windows setup to compile GIMP since most Linux distros will do this out of the box or very nearly so. Some linux distros will do a minimal install in as little as a half hour.
Hal
GIMP 2.3.4
Hal V. Engel wrote:
If all you need is enough of a Linux installation to get GIMP to build and to test GIMP then the amount of diskspace needed to do this is fairly small and you can free up a partition on your existing hard drive(s) to do this.
Good point. I thought of doing this myself, but in the past I've had to repartition my hard drive before a Linux install. Do most Linux distros now come equipped with a partition manager that can handle an NT partition and successfully resize it without destroying it? When I've previously done this, I've had to use Partition Magic which is the best proprietary software for this sort of thing, but even it had bugs in some prior versions that would crash an NT partition. If most Linux distros now come equipped with such a partition manager and I can trust that my NT partition will safely remain intact, I may reconsider my former statement. But my biggest concern is that, at present, without a partition manager, I've still got to invest another $50 on top of losses due to time. Not that that's a huge investment, but I've got other financial priorities that exceed an investment in a Partition Manager. Thanks in advance for your feedback.
Lance
GIMP 2.3.4
On Tuesday 04 October 2005 02:28 pm, Lance Dockins wrote:
Hal V. Engel wrote:
If all you need is enough of a Linux installation to get GIMP to build and to test GIMP then the amount of diskspace needed to do this is fairly small and you can free up a partition on your existing hard drive(s) to do this.
Good point. I thought of doing this myself, but in the past I've had to repartition my hard drive before a Linux install. Do most Linux distros now come equipped with a partition manager that can handle an NT partition and successfully resize it without destroying it? When I've previously done this, I've had to use Partition Magic which is the best proprietary software for this sort of thing, but even it had bugs in some prior versions that would crash an NT partition. If most Linux distros now come equipped with such a partition manager and I can trust that my NT partition will safely remain intact, I may reconsider my former statement. But my biggest concern is that, at present, without a partition manager, I've still got to invest another $50 on top of losses due to time. Not that that's a huge investment, but I've got other financial priorities that exceed an investment in a Partition Manager. Thanks in advance for your feedback.
Lance
Yes most distros come with a partition manager that can handle this. Of course, you should back things up just in case and it is a good idea to defrag the partition you are shrinking before you start. I have also used the partition manager in boot-it which you can get as a trial version for $0.
Hal
GIMP 2.3.4
On 10/4/05, Lance Dockins wrote:
this is so interesting. Win32 has succeeded in making linux expensive.
you are asking that the Win32 environment not work the way it was designed to work -- at least i think this is what you are saying.
i am very impressed that it was able to make free software expensive, this is a simply amazing accomplishment!
Carol,
Where in my e-mail did your read that *Linux *was going to cost me money? Read that sentence again. Or, better yet, I'll quote it. "I should also clarify that I have considered switching to Linux to make this easier, *but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world.*" Did I say that the money, time, and hardware I was going to invest was going to be invested in buying Linux or did I just say that I would have to invest money, time, and hardware into a Linux setup? Here's a few things that cost money that fit perfectly into that sentence.* Time
* A spare hard drive
* A reliable partition manager (instead of a drive) * Perhaps an alternate computer entirely * Potential other hardware for those components that Linux drivers don't function well on.Before I sign off on this, let me quote the second half of that sentence again. *"*But I just don't have the time, money, and hardware to do so *without destroying the Win32 environment I'm required to use in the professional world.*" So that pretty much eliminates installing over top of my current OS.
Nonsense. Debian's installer can resize ALL Win32 partitions (NTFS + FAT) and make room for itself nondestructively.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
GIMP 2.3.4
On 10/4/05, Tor Lillqvist wrote:
lode leroy writes:
> The thing is that for compiling gimp from cvs, you need quite some expertise > in the autotools, libtool, aclocal, pkg-config etc to fix those > not-100%-working-together- distributed binaries...> Would it be feasible to create a big zip-file that contains everything for > gimp for download?
It would be possible, but wouldn't such a zipfile just create open up the possibility for even more confusion when there would then be yet another distribution of these libs? (A long time ago I *did* distribute self-built jpeg, tiff, zlib and whatnot, but stopped doing that as there were other distributions, too, that were just as good, or even more directly from the source, like zlib.)
Since you've found these better sources, I know it'd be a pain, but could you include links to them somewhere? That way, we can use the same DLLs built that you do. (I'm presuming you don't already; if you do, my apologies.)
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
GIMP 2.3.4
On Tuesday 04 October 2005 16:37, lode leroy wrote:
Would it be feasible to create a big zip-file that contains everything for gimp for download?
If you call it "GIMP-toaster", many people will instantly recognise its purpose.
Cheers; Leon
GIMP 2.3.4
On Wednesday 05 October 2005 01:50, Lance Dockins wrote:
* Time
* A spare hard drive
* A reliable partition manager (instead of a drive) * Perhaps an alternate computer entirely * Potential other hardware for those components that Linux drivers don't function well on.
If you're in Australia, put a grant proposal to Linux Australia (www.linux.org.au). They'd probably be quite pleased to support GIMP development in this manner. The computer recycling places (like Computer Angels in WA and ComputerBank in Victoria) would also look favourably upon donating a machine to this cause.
Cheers; Leon
GIMP 2.3.4
On Wednesday 05 October 2005 03:11, Hal V. Engel wrote:
Windows and
Linux can live on the same machine with no problems. So you do not have to "destroy the Wind32 environment". Many of the folks on this list, myself included, have both Linux and Windows running on the machines they use on a daily basis. If all you need is enough of a Linux installation to get GIMP to build and to test GIMP then the amount of diskspace needed to do this is fairly small and you can free up a partition on your existing hard drive(s) to do this. In addition, most Linux distros are free. So this clearly does not take any money or new/additional hardware.
The real issue is time. Which is a valid concern but it might actually take less time and effort to get a working Linux environment than to mess around getting Windows setup to compile GIMP since most Linux distros will do this out of the box or very nearly so. Some linux distros will do a minimal install in as little as a half hour.
Lance, please pardon the distro-centric plug, but Mandriva Linux will resize partitions to suit (doing a defrag before you boot the installer helps), is very easy to set up and use (lots of nice GUI helpers), free to download and either of LILO or GRUB are more than adequate as boot managers for the complete system.
http://www.google.com.au/search?q=%222005-Limited-Edition-Download%22
Run this short script to set up a user's account for building RPMS:
http://mandrake.cyberknights.com.au/setup4rpm.sh
Install a source RPM for GIMP as that user, then copy a development tarball into rpm/SOURCES/ then tweak (with a text editor) the specfile at rpm/SPECS/gimp.spec to refer to it instead of the original, and you're away.
As Hal says, your main issue is going to be time. If you don't have an hour to stumble fearfully through a Linux installation, will you have time to do serious development?
Cheers; Leon
-- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/ Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/ Member, Linux Australia
GIMP 2.3.4
When installing Python from Python-2.4.1.msi, the headers are not in C:/Python24/include/python24 but in C:/Python24/include.
This fixes that problem.
--- pythondev.m4.orig 2005-10-05 17:29:40.015625000 -0700
+++ pythondev.m4 2005-10-05 17:27:01.609375000 -0700
@@ -10,9 +10,9 @@ AC_MSG_CHECKING(for headers required to
dnl deduce PYTHON_INCLUDES
py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
-PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
+PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}
-I${py_prefix}/
include"
if test "$py_prefix" != "$py_exec_prefix"; then
- PYTHON_INCLUDES="$PYTHON_INCLUDES
-I${py_exec_prefix}/include/python${PYTHON_
VERSION}"
+ PYTHON_INCLUDES="$PYTHON_INCLUDES
-I${py_exec_prefix}/include/python${PYTHON_
VERSION} -I${py_exec_prefix}/include"
fi
AC_SUBST(PYTHON_INCLUDES)
dnl check if the headers exist:
GIMP 2.3.4
On Wed, Oct 05, 2005 at 05:28:49PM +0200, lode leroy wrote:
When installing Python from Python-2.4.1.msi, the headers are not in C:/Python24/include/python24 but in C:/Python24/include.
Well, this is fixed differently in 2.3.4. I'm assuming you're using something older and neglected to change the subject...
-Yosh