working version of GTK for win64

[Oleg Tchij]

 Hello all,

 I've tried to build and run gtk for 64-bit Windows. At last I can upload
working version for usage:

http://rapidshare.com/files/130142295/gtk-2.12.9-win64-devel.zip.html
http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html

 As usual devel file contains executable and development files, src file -
complete development tree.

 For build I've use cross-compile mode for mingw compiler:

http://downloads.sourceforge.net/mingw-w64/mingw-w64-bin_x86-64-linux_20080705.tar.bz2

with CFLAGS="-s -O2 -mms-bitfields".

 One can build gtk applications using the same compiler or prepare MS Visual
Studio 2008 libraries from above with "lib.exe /MACHINE:x64 /DEF:file.def".
Both methods are working.

 According to my experience of porting I suggest the following patch in source
code of gtk and related libraries:

 1) for all ltmain.sh files in all packages glib, atk, cairo, pango, gtk in
function func_win32_libid () replace string

$EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then

to

$EGREP -e 'file format pe-(.*architecture: i386)?' >/dev/null ; then

  It allows libtool to recognize 64-bit dll files as shared libraries. Of
course win32 version also works with this perfectly.

 2) use the following main types definitions:

#define GLIB_SIZEOF_LONG   4
#define GLIB_SIZEOF_SIZE_T 8

and in glib/gmain.h for polling:

struct _GPollFD
{
#ifdef G_OS_WIN32
  void*         fd;
#else
  gint          fd;
#endif
  gushort       events;
  gushort       revents;
};

 3) for all Windows API calls in gtk/gdk/win32 use new declarations:
SetWindowLongPtr instead of SetWindowLong, GWLP_HWNDPARENT for
GWL_HWNDPARENT and so on.

 4) remove or disable c++ example (namely autotestkeywords.cc) in gtk/tests.

 In the development tree all my changes have copies of original files with
extentions .orig. Applications with 64-bit are tested on Windows Compute
Cluster Server 2003 (wccs). The same code is running successfully for win32
and wine with mingw for win32.

 If someone are interested in this version of code I can add same extra
descriptions or details. From my point of view it will be very useful to
incorporate code changes or some cleanups which work with win32 and win64
versions of gtk and we'll continue to use gtk libraries in more areas and
applications.

 Thanks in advance!

 Oleg Tchij,
 Head of High Performance Laboratory,
 UIIP NASB, Surganova 6,
 Minsk, Belarus
 http://uiip.bas-net.by/
 [phone]







 
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tor Lillqvist]

(Sorry for replying a bit late.)

>  I've tried to build and run gtk for 64-bit Windows. At last I can upload
> working version for usage:

Great! I hope people who are interested will try them out. (Personally
I don't have any machine running 64-bit Windows, unfortunately.)

> http://rapidshare.com/files/130142295/gtk-2.12.9-win64-devel.zip.html
> http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html

>  For build I've use cross-compile mode for mingw compiler:

Nice.

> with CFLAGS="-s -O2 -mms-bitfields".

Is the -mms-bitfields flag still needed for Win64? I am a bit
disappointed in that case, why can't they simply make it the default?
Presumably for Win32 it was noticed only when gcc had been available
for a while that there are differences in struct packing compared to
the "official" ABI, and they then introduced that switch (which
actually first was named -fnative-struct). But as gcc for Win64 is a
relatively recent development, why not be struct packing compatible
with MSVC from the beginning?

> $EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then

> to
> $EGREP -e 'file format pe-(.*architecture: i386)?' >/dev/null ; then

Hmm, this needs to be filed in upstream libtool, I guess. Will take a
while before such a patch, if accepted, then trickles down into actual
tarballs, of course. So that is then something one must take care of
as part of the build process, add to one's build scripts.

> and in glib/gmain.h for polling:
>
> #ifdef G_OS_WIN32
>  void*         fd;
> #else
>  gint          fd;
> #endif

Hmm, GLib already has:

#if defined (G_OS_WIN32) && GLIB_SIZEOF_VOID_P == 8
  gint64 fd;
#else
  gint fd;
#endif

isn't that enough?

>  3) for all Windows API calls in gtk/gdk/win32 use new declarations:
> SetWindowLongPtr instead of SetWindowLong, GWLP_HWNDPARENT for
> GWL_HWNDPARENT and so on.

Could you produce a proper patch, and file a bug and attach the patch please?

> From my point of view it will be very useful to
> incorporate code changes or some cleanups which work with win32 and win64
> versions of gtk and we'll continue to use gtk libraries in more areas and
> applications.

Yep. I will work on integrating the necessary changes into trunk in SVN.

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Richard Hult]

Oleg Tchij wrote:
>  I've tried to build and run gtk for 64-bit Windows. At last I can upload
> working version for usage:

Nice, good to see!

>  2) use the following main types definitions:
>
> #define GLIB_SIZEOF_LONG   4
> #define GLIB_SIZEOF_SIZE_T 8

I have been doing some 64-bit building as well, and used the attached
patch for the sizes/types.

/Richard

--
Imendio AB - Expert solutions in GTK+
http://www.imendio.com

diff --git a/glib-2.14.6/glibconfig.h.win32 b/glib-2.14.6/glibconfig.h.win32
index 62eda5f..093eaed 100644
--- a/glib-2.14.6/glibconfig.h.win32
+++ b/glib-2.14.6/glibconfig.h.win32
@@ -64,6 +64,24 @@ typedef unsigned __int64 guint64;
 #define G_GINT64_FORMAT "I64i"
 #define G_GUINT64_FORMAT "I64u"
 
+#if defined(_M_X64) || defined(_M_AMD64)
+
+#define GLIB_SIZEOF_VOID_P 8
+#define GLIB_SIZEOF_LONG   4
+#define GLIB_SIZEOF_SIZE_T 8
+
+typedef signed long long gssize;
+typedef unsigned long long gsize;
+#define G_GSIZE_MODIFIER "I64"
+#define G_GSSIZE_FORMAT "I64d"
+#define G_GSIZE_FORMAT "I64u"
+
+#define G_MAXSIZE G_MAXUINT64
+#define G_MINSSIZE G_MININT64
+#define G_MAXSSIZE G_MAXINT64
+
+#else
+
 #define GLIB_SIZEOF_VOID_P 4
 #define GLIB_SIZEOF_LONG   4
 #define GLIB_SIZEOF_SIZE_T 4
@@ -78,6 +96,8 @@ typedef unsigned int gsize;
 #define G_MINSSIZE G_MININT
 #define G_MAXSSIZE G_MAXINT
 
+#endif
+
 typedef gint64 goffset;
 #define G_MINOFFSET G_MININT64
 #define G_MAXOFFSET G_MAXINT64

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tor Lillqvist]

> I have been doing some 64-bit building as well, and used the attached patch
> for the sizes/types.

Thanks. Committed to trunk.

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tor Lillqvist]

> http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html

A couple of questions about your changes in the source:

In glib's configure.in, you do:

--- ./configure.in.orig 2008-05-09 22:50:12.000000000 +0300
+++ ./configure.in 2008-05-06 12:10:18.000000000 +0300
@@ -871,6 +871,9 @@
   $ac_cv_sizeof_long)
       glib_size_type=long
       ;;
+  $ac_cv_sizeof_long_long)
+      glib_size_type=int64
+      ;;
   *)  AC_MSG_ERROR([No type matching size_t in size])
       ;;
 esac

What is this int64 type? Is it a predefined type in gcc for win64? Is
it available also when more strict standard conformance is asked for?
What about MSVC? Shouldn't __int64 be used instead? Or probably long
long. Anyway, if you add a new possible value for glib_size_type, more
changes are needed later in configure.in where it does a

case $glib_size_type in
...

I also notice that configure.in tests:

case $ac_cv_sizeof_void_p in
$ac_cv_sizeof_int)   glib_gpi_cast=''        glib_gpui_cast=''         ;;
$ac_cv_sizeof_long) glib_gpi_cast='(glong)' glib_gpui_cast='(gulong)' ;;
*) glib_unknown_void_p=yes ;;
esac

Surely ac_cv_sizeof_void_p will be 8? Won't that then set
glib_unknown_void_p=yes which will cause echo '#error SIZEOF_VOID_P
unknown - This should never happen' ?

I downloaded the 64-bit mingw cross-compiler (the one hosted on 32-bit
Windows) and tested cross-compiling. But actually I really should
install 64-bit XP or Vista on some suitable machine. Not that I have
that many to choose from.. it will have to be the one in the living
room that mostly acts as a media machine now.

I committed a change to configure.in in trunk that (as far as I can
see) when run using 64-bit mingw produces a correct glibconfig.h that
matches rhult's patch in this thread. I still need to go through your
changes and commit them as such or slightly modified. I will also make
sure it compiles for 64 bits without warnings.

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Oleg Tchij]

On Thursday 24 July 2008 03:54:07 Tor Lillqvist wrote:

> > http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html
>
> A couple of questions about your changes in the source:
>
> In glib's configure.in, you do:
>
> --- ./configure.in.orig 2008-05-09 22:50:12.000000000 +0300
> +++ ./configure.in 2008-05-06 12:10:18.000000000 +0300
> @@ -871,6 +871,9 @@
>    $ac_cv_sizeof_long)
>        glib_size_type=long
>        ;;
> +  $ac_cv_sizeof_long_long)
> +      glib_size_type=int64
> +      ;;
>    *)  AC_MSG_ERROR([No type matching size_t in size])
>        ;;
>  esac
>
> What is this int64 type? Is it a predefined type in gcc for win64? Is
> it available also when more strict standard conformance is asked for?
> What about MSVC? Shouldn't __int64 be used instead? Or probably long
> long. Anyway, if you add a new possible value for glib_size_type, more
> changes are needed later in configure.in where it does a

 First of all, configure script is used only for gcc and automake routines.
This part of script requires an predefined type in one word (!) which has the
size of "long long". In this case, int64 is correct answer for win32 and
win64.

>
> case $glib_size_type in
> ...
>
> I also notice that configure.in tests:
>
> case $ac_cv_sizeof_void_p in
> $ac_cv_sizeof_int)   glib_gpi_cast=''        glib_gpui_cast=''         ;;
> $ac_cv_sizeof_long) glib_gpi_cast='(glong)' glib_gpui_cast='(gulong)' ;;
> *) glib_unknown_void_p=yes ;;
> esac
>
> Surely ac_cv_sizeof_void_p will be 8? Won't that then set
> glib_unknown_void_p=yes which will cause echo '#error SIZEOF_VOID_P
> unknown - This should never happen' ?

 Currently my glibconfig.h is hand made for win64. If we fix SIZEOF_VOID_P at
the same time it will be good. Also we should use

#ifdef  __cplusplus
#define G_HAVE_INLINE   1
#else   /* !__cplusplus */
#ifndef _MSC_VER
#define G_HAVE_INLINE 1
#endif /* _MSC_VER */
#define G_HAVE___INLINE 1
#if !defined(_MSC_VER) && !defined(__DMC__)
#define G_HAVE___INLINE__ 1
#endif /* !_MSC_VER and !__DMC__ */
#endif  /* !__cplusplus */

#define G_CAN_INLINE    1

instead of

#ifdef  __cplusplus
#define G_HAVE_INLINE   1
#else   /* !__cplusplus */
#define G_HAVE_INLINE 1
#define G_HAVE___INLINE 1
#define G_HAVE___INLINE__ 1
#endif  /* !__cplusplus */

#ifdef  __cplusplus
#define G_CAN_INLINE    1
#else   /* !__cplusplus */
#define G_CAN_INLINE    1
#endif

for correct MSVC build of applications.

>
> I downloaded the 64-bit mingw cross-compiler (the one hosted on 32-bit
> Windows) and tested cross-compiling. But actually I really should
> install 64-bit XP or Vista on some suitable machine. Not that I have
> that many to choose from.. it will have to be the one in the living
> room that mostly acts as a media machine now.
>
> I committed a change to configure.in in trunk that (as far as I can
> see) when run using 64-bit mingw produces a correct glibconfig.h that
> matches rhult's patch in this thread. I still need to go through your
> changes and commit them as such or slightly modified. I will also make
> sure it compiles for 64 bits without warnings.

 In any case during compilation we'll have a lot of warnings about INT to
POINTER conversions. But whenever the value of int less than 2^32 it works
correctly for win64.

>
> --tml

 Oleg Tchij


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Oleg Tchij]

On Wednesday 23 July 2008 12:50:46 Tor Lillqvist wrote:

> (Sorry for replying a bit late.)
>
> >  I've tried to build and run gtk for 64-bit Windows. At last I can upload
> > working version for usage:
>
> Great! I hope people who are interested will try them out. (Personally
> I don't have any machine running 64-bit Windows, unfortunately.)
>
> > http://rapidshare.com/files/130142295/gtk-2.12.9-win64-devel.zip.html
> > http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html
> >
> >  For build I've use cross-compile mode for mingw compiler:
>
> Nice.
>
> > with CFLAGS="-s -O2 -mms-bitfields".
>
> Is the -mms-bitfields flag still needed for Win64? I am a bit
> disappointed in that case, why can't they simply make it the default?
> Presumably for Win32 it was noticed only when gcc had been available
> for a while that there are differences in struct packing compared to
> the "official" ABI, and they then introduced that switch (which
> actually first was named -fnative-struct). But as gcc for Win64 is a
> relatively recent development, why not be struct packing compatible
> with MSVC from the beginning?
>

 I've used -mms-bitfields setting as analog for win32 build instructions.
Without this switch everything works also whenever the same setting (!) used
for libraries and applications build (otherwise not !), but I am not sure
about MSVC compatibility in this case. It should be checked.

> > $EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
> >
> > to
> > $EGREP -e 'file format pe-(.*architecture: i386)?' >/dev/null ; then
>
> Hmm, this needs to be filed in upstream libtool, I guess. Will take a
> while before such a patch, if accepted, then trickles down into actual
> tarballs, of course. So that is then something one must take care of
> as part of the build process, add to one's build scripts.
>
> > and in glib/gmain.h for polling:
> >
> > #ifdef G_OS_WIN32
> >  void*         fd;
> > #else
> >  gint          fd;
> > #endif
>
> Hmm, GLib already has:
>
> #if defined (G_OS_WIN32) && GLIB_SIZEOF_VOID_P == 8
>   gint64 fd;
> #else
>   gint fd;
> #endif
>
> isn't that enough?

 If latter on we used fd as an HANDLE in WIN API calls, then above
declarations is correct and works for win32 and win64.

>
> >  3) for all Windows API calls in gtk/gdk/win32 use new declarations:
> > SetWindowLongPtr instead of SetWindowLong, GWLP_HWNDPARENT for
> > GWL_HWNDPARENT and so on.
>
> Could you produce a proper patch, and file a bug and attach the patch
> please?

 For MS Windows build we should clarify about usage of new calls, because the
are no SetWindowLongPtr and GWLP_HWNDPARENT declarations for MSVC version 6.
So if we confirm that gtk should be on win64, then use mingw or MSVC version
7 (2003), 8 (2005) and 9 (2008). Current patch works only for above
compilers.

>
> > From my point of view it will be very useful to
> > incorporate code changes or some cleanups which work with win32 and win64
> > versions of gtk and we'll continue to use gtk libraries in more areas and
> > applications.
>
> Yep. I will work on integrating the necessary changes into trunk in SVN.
>
> --tml


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tor Lillqvist]

>  First of all, configure script is used only for gcc and automake routines.

Currently, in practise, yes. It is quite possible that at some point
automake and libtool could handle also a build that uses the Microsoft
compiler. (Either through directly supporting it, or by using some
wrapper. There are a few such wrappers already, and I have too been
tinkering on one now and then, see
http://svn.gnome.org/viewvc/build/trunk/win32/cl-wrapper.c?view=log )

And then there are other compilers for Windows than gcc and
Microsoft's, too, like Intel's for instance.

> This part of script requires an predefined type in one word (!) which has the
> size of "long long". In this case, int64 is correct answer for win32 and win64.

It doesn't have to be one word. Just adding some quotes to
configure.in makes "long long" work fine, too, I think. And __int64 is
the more portable name for a 64-bit integer on Windows, I would say.
("portable" in the sense known to both MSVC and gcc.)

> Also we should use
[ inline stuff ]

OK, will check and fix.

>  In any case during compilation we'll have a lot of warnings about INT to
> POINTER conversions.

Yep. I will try to get rid of those.

(Now running 64-bit Vista on the "living room" computer, so I can
actually even run the 64-bit GTK+ stack eventually...)

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tor Lillqvist]

> Also we should use
> [...]

> instead of
> [...]

> for correct MSVC build of applications.

If you check glibconfig.h.win32.in you will see that it already does
it exactly like you say. glibconfig.h.win32.in is a hand-maintained
file that includes _MSC_VER ifdefs, from which the glibconfig.h that
is in the official GLib Win32 packages on ftp.gnome.org is generated.

A glibconfig.h generated by the configure script is as such not usable
by other compilers than that which the configure script used, and
should thus not be distributed as part of developer packages that
claim to be usable by several compilers.

--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list