Hi Gimp team,

are you still looking for a Windows developer? Recently I've spent couple of days, or maybe weeks, to compile Gimp for Windows, 32bit. In the end I have a working Gimp, version 2.8.2. I have built the whole GNU chain, starting with zlib through gtk+-2.0 and ending with Gimp, using the most recent stable versions of all the necessary packages. Today I quickly went through the list of Windows related bugs and it looks like lots of them have gone.

My initial intention was only to have a working build so that I could compile my plugin for Windows. But now, when I invested so much work in it, it would perhaps be good to share the whole work. I can create a new Windows installer using msi and also build 64bit version.

Would there be an interest in this? If yes, it would certainly require lots of other discussion of what to include in the final package and what to fix. I saw for example a request for the LANG environment variable. I can confirm that this does not work anymore in the 2.8.2 version, but should be quite easy to add it.

So I am waiting for your thoughts and ideas.

Thanks, Pavel

Hi Skand,

here is a detailed guide of how to compile the dependencies. First of all, I used MinGW64 cross compiler (Ruben's personal build) to build both 32 and 64bit versions of Gimp. 32bit version works on Windows XP and newer, 64bit version works on Win7, does not work on XP 64bit, I suppose it would work on Vista and newer. I cannot see any issue like instability or malfunctions.

zlib - I wasn't able to run configure for cross-compilation here, fortunately this is an easy piece of code, so make can be called directly with Makefile.gcc
libffi - no problems from here onwards until I mention some libiconv
libxml2
gettext
glib - this is a bit tricky. I don't want to go into details, but there are several issues with it and requires lots of manual intervention. I can perhaps describe all the issues in a separate thread, if someone request that
gtk-doc - no problems
atk - does not want to build shared library for 64bit version. Generated libtool must be manually edited to go through. libpng - no problems again
jpeg-8d
jasper
tiff
gdk-pixbuf
freetype
fontconfig
lcms (taken from ghostscript source) lcms2
jbig2dec (taken from ghostscript source)

ghostscript - this is really hard one. In the end I created my own script to build libgs.dll

libspectre - no problems again poppler
pixman - must be configured with --disable-sse2 !!! Otherwise Gimp gets very unstable, at least on virtual XP SP3 cairo - no problems from now till the end harfbuzz
pango
libcroco
librsvg
libexif
libmng
iso-codes
gtk+
babl
gegl
GIMP !!!

Some final thoughts. The configure and libtool are very often so clever that they refuse to build shared libraries even if all the required dependencies exist. libtool must be manually edited and then it builds them OK. The extra mentioned atk package is an exception to this role - they are even more clever here for the 64bit cross-compilation that much bigger portion of libtool must be commented out.

For this reason it is almost impossible to create an automated script which would do all the job. Or at least I am not skilled enough for that.

I don't know whether the sequence I gave here is an optimal one, but it works. I hope it will be helpful anyway.

Pavel

On Thu, 2013-01-10 at 15:11 +0530, Skand Hurkat wrote:

Could you provide a list of steps that went into compiling the dependencies? I have been trying to compile a similar list of dependencies for Win64 (using MinGW64), and have found very little, and/or scattered documentation for the same. A consolidated list of steps, or even better, a shell script that does the job will be highly appreciated.

Regards, Skand.

On 09-01-2013 15:05, pavel wrote:

Hi Gimp team,

are you still looking for a Windows developer? Recently I've spent couple of days, or maybe weeks, to compile Gimp for Windows, 32bit. In the end I have a working Gimp, version 2.8.2. I have built the whole GNU chain, starting with zlib through gtk+-2.0 and ending with Gimp, using the most recent stable versions of all the necessary packages. Today I quickly went through the list of Windows related bugs and it looks like lots of them have gone.

My initial intention was only to have a working build so that I could compile my plugin for Windows. But now, when I invested so much work in it, it would perhaps be good to share the whole work. I can create a new Windows installer using msi and also build 64bit version.

Would there be an interest in this? If yes, it would certainly require lots of other discussion of what to include in the final package and what to fix. I saw for example a request for the LANG environment variable. I can confirm that this does not work anymore in the 2.8.2 version, but should be quite easy to add it.

So I am waiting for your thoughts and ideas.

Thanks, Pavel

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hello Tobias,

you are right, I should get the latest snapshot and try to fix some issues. I know the list.

Thanks, Pavel

On Thu, 2013-01-10 at 16:59 +0100, Tobias Jakobs wrote:

Hello Pavel,

I'm not a developer, but a quick look into the buglist shows still al lott of open Windows bugs:

https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP;op_sys=Windows

And i think if you are interested in developing you should try to build gimp from git master, too.

Regards

Tobias

On Wed, Jan 9, 2013 at 10:35 AM, pavel wrote: Hi Gimp team,

are you still looking for a Windows developer? Recently I've spent
couple of days, or maybe weeks, to compile Gimp for Windows, 32bit. In
the end I have a working Gimp, version 2.8.2. I have built the whole GNU
chain, starting with zlib through gtk+-2.0 and ending with Gimp, using
the most recent stable versions of all the necessary packages. Today I
quickly went through the list of Windows related bugs and it looks like
lots of them have gone.

My initial intention was only to have a working build so that I could
compile my plugin for Windows. But now, when I invested so much work in
it, it would perhaps be good to share the whole work. I can create a new
Windows installer using msi and also build 64bit version.
Would there be an interest in this? If yes, it would certainly require
lots of other discussion of what to include in the final package and
what to fix. I saw for example a request for the LANG environment
variable. I can confirm that this does not work anymore in the 2.8.2
version, but should be quite easy to add it.
So I am waiting for your thoughts and ideas.
Thanks, Pavel

_______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, 2013-01-11 at 13:44 +0100, Michael Schumacher wrote:

Von: Skand Hurkat

Thanks for the steps Pavel.

As for the changes to libtool and other manual intervention steps, maybe you could offer patches for the same? I tried scripting the whole thing, so that it fetches the archive using wget, unpacks it, applies the needed patches, and then configures and compiles it. However, I ran into some difficulties with dependencies on Python libs.

Just a quick addition:

I hope everyone realizes that it is not necessary to compile all the dependencies when building GIMP on the Windows platform. There are prebuilt binaries - for example, the installers from http://gimpü-win.sf.net are built with the OpenSUSE mingw packages:

http://download.opensuse.org/repositories/windows:/mingw/

Yes, this is just a kind of adrenalin sport from my side :-)

Pavel

HTH,
Michael
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi Skand,

I have disabled Python support in my build. I tried to build Python and also found it not straightforward, so I've just skipped it for now.

Regarding the libtool changes, there is the following code usually generated:

# Check to see if the archive will have undefined symbols. if test "$allow_undefined" = yes; then if test "$allow_undefined_flag" = unsupported; then func_warning "undefined symbols not allowed in $host shared libraries"
build_libtool_libs=no
build_old_libs=yes
fi
else
# Don't allow undefined symbols.
allow_undefined_flag="$no_undefined_flag" fi

Sometimes it is OK, but sometimes it prevents the shared library (dll) to be built. So I always comment out the two lines:

# build_libtool_libs=no # build_old_libs=yes

Then it goes fine. As I wrote before, atk 64bit is an exception, it has even stronger check. The whole following code must be commented out, and it appears in libtool twice!!! :

# if test -n "$a_deplib" ; then # droppeddeps=yes
# $ECHO
# $ECHO "*** Warning: linker path does not have real file for library $a_deplib."
# $ECHO "*** I have the capability to make that library automatically link in when"
# $ECHO "*** you link to this library. But I can only do this if you have a"
# $ECHO "*** shared version of the library, which you do not appear to have"
# $ECHO "*** because I did check the linker path looking for a file starting"
# if test -z "$potlib" ; then
# $ECHO "*** with $libname but no candidates were found. (...for regex pattern test)"
# else
# $ECHO "*** with $libname and none of the candidates passed a file format test"
# $ECHO "*** using a regex pattern. Last file checked: $potlib" # fi
# fi

My problem is that I am not any good in autotools and in linux scripting in general. So I probably will not be able to help you with this more.

I can try to pay more attention to Python, but I think it would be better if I focus on some Windows related bugs, since I feel a little bit stronger on this field :-)

Pavel

On Fri, 2013-01-11 at 16:20 +0530, Skand Hurkat wrote:

Thanks for the steps Pavel.

As for the changes to libtool and other manual intervention steps, maybe you could offer patches for the same? I tried scripting the whole thing, so that it fetches the archive using wget, unpacks it, applies the needed patches, and then configures and compiles it. However, I ran into some difficulties with dependencies on Python libs.
I don't have the exact error messages right now; but I really did not find any working solution for those errors.

Regards, Skand.

Hi Sven,

thank you for your e-mail. I'll not go back to previous paragraphs and try to explain something here.

The idea about creating my own installer came from some forums where I've got an impression that there is no 64bit version of Gimp for Windows at the moment, or is unstable or buggy. Then I realized that there is something, so I will postpone this effort.

Regarding the bugs which seem to be fixed in my build, it's perhaps more my impression than a fact. I quickly checked few of them and could not reproduce for example 676708, 690749, 658919, 674928 and 691227. So I concluded that this might be because I have my own builds of the shared libraries.

Anyway, all the issues certainly need deeper investigation. I think I could help you with some of them. I tried to make a fix for 691169 (Japanese characters in the file name) and I have a workaround for the problem (without the need to modify GLib, although it would deserve some improvement). It will perhaps not be accepted because it is too much hack, but I can try it.

So my next two questions are:

1) How can I submit/propose a patch?

2) Is there any coordinator who would assign bugs to a particular developer? So that two or more people don't work on the same issue?

Thanks, Pavel

On Fri, 2013-01-11 at 19:30 +0100, scl wrote:

On 09.01.13 at 10:35 AM pavel wrote > are you still looking for a Windows developer? Welcome to the club, Pavel ;-)
Your lines about building efforts sound similar to my experiences and I decided to support GIMP on Windows, too. Currently I'm stepping deeper into Windows development for GIMP (besides other things).

> Today I quickly went through the list of Windows related bugs and it > looks like lots of them have gone. Hmm, that sounds new to me. Together with mainly Michael Schumacher I lately checked nearly all bugs and reduced the amount of open Windows bugs down to approx. 40%. The open bugs you see now are yet open to be fixed. But nobody is perfect - if you see something actually obsolete, then add a comment to that particular bug in Bugzilla.

> I can create a new > Windows installer using msi and also build 64bit version. To avoid duplicate and unnecessary work it's best to come to IRC and speak with Jernej Simoncic or Michael Henning. They maintain the Sourceforge build resp. the nightly builds.

Kind regards,

Sven

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi Sven,

thank you for your e-mail. I'll not go back to previous paragraphs and try to explain something here.

The idea about creating my own installer came from some forums where I've got an impression that there is no 64bit version of Gimp for Windows at the moment, or is unstable or buggy. Then I realized that there is something, so I will postpone this effort.

Regarding the bugs which seem to be fixed in my build, it's perhaps more my impression than a fact. I quickly checked few of them and could not reproduce for example 676708, 690749, 658919, 674928 and 691227. So I concluded that this might be because I have my own builds of the shared libraries.

Anyway, all the issues certainly need deeper investigation. I think I could help you with some of them. I tried to make a fix for 691169 (Japanese characters in the file name) and I have a workaround for the problem (without the need to modify GLib, although it would deserve some improvement). It will perhaps not be accepted because it is too much hack, but I can try it.

So my next two questions are:

1) How can I submit/propose a patch?

2) Is there any coordinator who would assign bugs to a particular developer? So that two or more people don't work on the same issue?

Thanks, Pavel

On Fri, 2013-01-11 at 19:30 +0100, scl wrote:

On 09.01.13 at 10:35 AM pavel wrote > are you still looking for a Windows developer? Welcome to the club, Pavel ;-)
Your lines about building efforts sound similar to my experiences and I decided to support GIMP on Windows, too. Currently I'm stepping deeper into Windows development for GIMP (besides other things).

> Today I quickly went through the list of Windows related bugs and it > looks like lots of them have gone. Hmm, that sounds new to me. Together with mainly Michael Schumacher I lately checked nearly all bugs and reduced the amount of open Windows bugs down to approx. 40%. The open bugs you see now are yet open to be fixed. But nobody is perfect - if you see something actually obsolete, then add a comment to that particular bug in Bugzilla.

> I can create a new > Windows installer using msi and also build 64bit version. To avoid duplicate and unnecessary work it's best to come to IRC and speak with Jernej Simoncic or Michael Henning. They maintain the Sourceforge build resp. the nightly builds.

Kind regards,

Sven

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi Jehan,

On Tue, 2013-01-22 at 14:28 +0900, Jehan Pagès wrote:

Hi,

On Thu, Jan 10, 2013 at 8:46 PM, pavel wrote: Hi Skand,

here is a detailed guide of how to compile the dependencies. First of
all, I used MinGW64 cross compiler (Ruben's personal build) to build
both 32 and 64bit versions of Gimp. 32bit version works on Windows XP
and newer, 64bit version works on Win7, does not work on XP 64bit, I
suppose it would work on Vista and newer. I cannot see any issue like
instability or malfunctions.
zlib - I wasn't able to run configure for cross-compilation here,
fortunately this is an easy piece of code, so make can be called
directly with Makefile.gcc
libffi - no problems from here onwards until I mention some libiconv
libxml2
gettext
glib - this is a bit tricky. I don't want to go into details, but there
are several issues with it and requires lots of manual intervention. I
can perhaps describe all the issues in a separate thread, if someone
request that
gtk-doc - no problems
atk - does not want to build shared library for 64bit version. Generated
libtool must be manually edited to go through. libpng - no problems again
jpeg-8d
jasper
tiff
gdk-pixbuf
freetype
fontconfig
lcms (taken from ghostscript source) lcms2
jbig2dec (taken from ghostscript source)
ghostscript - this is really hard one. In the end I created my own
script to build libgs.dll

libspectre - no problems again poppler
pixman - must be configured with --disable-sse2 !!! Otherwise Gimp gets
very unstable, at least on virtual XP SP3 cairo - no problems from now till the end harfbuzz
pango
libcroco
librsvg
libexif
libmng
iso-codes
gtk+
babl
gegl
GIMP !!!

Impressive list. I would have abandoned before...

In any case, for it to be more useful, details are better because that make a lot of difference:

- which version you installed for each dependency (that can change much)

Basically I used the most recent stable version at the time when I was compiling.

- which compile option

This would be quite a long list. The best packages are happy with PKG_CONFIG_PATH, the worse need some more.

Still I would say that you made too much effort (as impressive as they are). As Mitch said, you should not have to compile this all (the wiki page that Alexandre linked contains all the details to make a simple cross-compile environment).

Well, it would certainly be easier just to install the binaries and only compile babl, gegl and gimp. On the other hand, if I don't have the full source compiled, I could hardly find this bug, for example: https://bugzilla.gnome.org/show_bug.cgi?id=692232 This one really annoyed me much since I don't like the single window mode :-) Now I have my patch included in my Windows build and I am happy.

Some final thoughts. The configure and libtool are very often so clever
that they refuse to build shared libraries even if all the required
dependencies exist. libtool must be manually edited and then it builds
them OK. The extra mentioned atk package is an exception to this role -
they are even more clever here for the 64bit cross-compilation that much
bigger portion of libtool must be commented out.

Could you be more specific? What do you mean by "editing libtool"? Are you sure you simply have not set your environment variables to point to the right prefixes for your cross-compiled environment *instead of* your normal environment (/usr/ and /usr/local usually)?

By "editing libtool" I mean to open the generated "libtool" file (generated bu configure) in a text editor and comment out some lines preventing shared libraries to be built.

Do you think it is possible to cross compile something like gimp and all its dependencies without having set the right prefixes etc.? :-)

Once again the wiki page has some information on which such environment variables to set (note that there may be other env variables good to set. In any case it is rarely a good idea to do too specific configuration for a generic compilation environment).

For this reason it is almost impossible to create an automated script
which would do all the job. Or at least I am not skilled enough for
that.

Well as I said, the wiki gives all this information. And it is perfectly automatable. Actually I know it, because I wrote such a script, using my wiki notes. :-)

I have a command line which allows me to create and enter cross-compilation environments in both 32 and 64 bits in 1 line (obviously it does not compile all the chain like you do! I use pre-compiled packages as in the wiki).

Well, if you only compile babl, gegl and gimp, then I can imagine that such a script may work.

I don't know whether the sequence I gave here is an optimal one, but it
works. I hope it will be helpful anyway.

And I hope my comments were useful too. I don't want to look like I am negative. I just try to simplify your process. Plus, that should ease your work and give you more time for actual bug fixing!

Have fun!

Yes, I am very thankful for your comments. As I explained, sometimes I like to have a full control over what I am doing. And as I showed the problem with growing tool windows, the source of errors might be much deeper than in the few top packages.

Anyway, I have quite working environment now and I can focus on fixing some reported bugs.

Pavel

Jehan

Pavel


On Thu, 2013-01-10 at 15:11 +0530, Skand Hurkat wrote: > Could you provide a list of steps that went into compiling the
> dependencies? I have been trying to compile a similar list of
> dependencies for Win64 (using MinGW64), and have found very little,
> and/or scattered documentation for the same. > A consolidated list of steps, or even better, a shell script that does
> the job will be highly appreciated. >
> Regards,
> Skand.
>
> On 09-01-2013 15:05, pavel wrote: > > Hi Gimp team,
> >
> > are you still looking for a Windows developer? Recently I've spent
> > couple of days, or maybe weeks, to compile Gimp for Windows, 32bit. In
> > the end I have a working Gimp, version 2.8.2. I have built the whole GNU
> > chain, starting with zlib through gtk+-2.0 and ending with Gimp, using
> > the most recent stable versions of all the necessary packages. Today I
> > quickly went through the list of Windows related bugs and it looks like
> > lots of them have gone.
> >
> > My initial intention was only to have a working build so that I could
> > compile my plugin for Windows. But now, when I invested so much work in
> > it, it would perhaps be good to share the whole work. I can create a new
> > Windows installer using msi and also build 64bit version. > >
> > Would there be an interest in this? If yes, it would certainly require
> > lots of other discussion of what to include in the final package and
> > what to fix. I saw for example a request for the LANG environment
> > variable. I can confirm that this does not work anymore in the 2.8.2
> > version, but should be quite easy to add it. > >
> > So I am waiting for your thoughts and ideas. > >
> > Thanks, Pavel
> >
> > _______________________________________________ > > gimp-developer-list mailing list > > gimp-developer-list@gnome.org > >
https://mail.gnome.org/mailman/listinfo/gimp-developer-list >
> _______________________________________________ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list