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

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.

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

> > 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

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

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

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

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

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

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 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

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?

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

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...

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.

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

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 +0300

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.

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

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

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 +0300

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.

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

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

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

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?

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

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

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

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

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.

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.

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

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

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

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:

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