Re: [Mingw-cross-env-list] updated gtk

[Mark Brand]

 This is a reply to Tony and Volker's reply.

> mmm... I was going to spend this weekend sorting out the OSX issues
> with the native glib build, the gcc 4.0 requirement means we can't use
> the cloog/ppl optimisations (until gcc4.6).

I hope I haven't caused too much trouble. We could always roll this back 
if it's premature. Maybe it was an exercise on my part that got out of 
control..

> Strange that they're doing a release (even) with a dev (odd glib) again.

We just went from glib 2.25.7 to 2.25.17. I don't think 2.26 has arrived 
yet.

> > >  http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/d4914002cfa5
> > >
> > >  I made some changes to the way the patches are organized. For glib, there
> > >  were several different files for patches.
> AFAIK, some of these were submitted upstream already.

You are right. It was sloppy of me to say (below) that the previous 
patches for both glib and gtk were unsuitable for upstream. I should not 
have included glib in that remark.

> > >  I combined this into one "fixes"
> > >  file containing the separate patches. The main reason for this is that it
> > >  goes well with using a tool like git or mercurial to maintain and prepare
> > >  the patches.
> Clearly not accepted/applied yet, there's no patch errors (and glib
> builds fine).

The glib patching did change some.

> > >  gtk.mk had lots of "sed" edits. I converted these to real diff patches. Part
> > >  of the motivation for this is to make it easier to tell when something
> > >  changes when we upgrade to new versions. The different patches are also in
> > >  one "fixes" file.
> Nice, I wasn't game to touch it, but gtk needs some attention;
> pkg-config is missing some libs and the size of the test programs
> causes some concern:
>
> test-qt.exe 11M
> test-gtk.exe 29M
> test-gtkmm.exe 73M

Do you have ideas about how bad, unexpected and avoidable this is? Is 
this an inescapable characteristic of static linking?

> > >  Most of the hard work had already been done. I mostly just had to figure out
> > >  how to apply the patches to the new sources.
> > >
> > >  In both cases, the patches are ad-hoc hacks, not suitable for submitting
> > >  upstream.
> > >
> > >  Please try this out. Comments (and patches!) are welcome.
> Shall do, I don't have a windows available to test at the moment, but
> gtk/glib are building successfully. Some dependents are failing, first
> is the gtkglext test program:
>
> diff -r d4914002cfa5 src/gtkglext.mk
> --- a/src/gtkglext.mk   Fri Sep 24 16:33:16 2010 +0200
> +++ b/src/gtkglext.mk   Sat Sep 25 02:08:48 2010 +1000
> @@ -44,5 +44,6 @@
>       '$(TARGET)-gcc' \
>           -W -Wall -ansi -pedantic \
>           '$(2).c' -o '$(PREFIX)/$(TARGET)/bin/test-gtkglext.exe' \
> -        `'$(TARGET)-pkg-config' gtkglext-1.0 --cflags --libs`
> +        `'$(TARGET)-pkg-config' gtkglext-1.0 --cflags --libs` \
> +        -ldnsapi
>   endef
>
> The librsvg test program is having similar linking problems, I'll do
> further testing tomorrow.


> This doesn't look "right" to me. If the '-ldnsapi' is missing in
> the pkg-config script of gtkglext (gtkglext-1.0.pc), it should
> be fixed there. Please revert the test compile command to the
> minimum, as this is the way other people will use to build their
> programs.
>
> Also, is the package that contains the "dnsapi" library already
> mentioned int the $(PKG)_DEPS of gtkglext?

I think that -ldnsapi issue might be a question of fixing up one of the 
gio .pc files. Haven't had time to pursue this. Any volunteers? :)

Mark