[Gtk-sharp-list] 64bit Gtk# for windows

[Mike Kestner]

On Wed, 2008-09-17 at 18:25 +0200, Jaroslav Šmíd wrote:
>   
> Yeah, sorry for that ... I'm already compilling GtkSharp assemblies 
> (sources are from SVN repo) on Windows x64 platform using my custom 
> makefiles. I've got glib-sharp, Mono.Cairo, pango-sharp, atk-sharp, 
> gdk-sharp and gtk-sharp already compiled - now it is time for gtkdotnet, 
> glade-sharp and maybe something else. I will upload it all tomorrow and 
> post a link here. I can provide those makefiles, but I doubt you want 
> them as you no longer want to support windows makefiles (stated in 
> /makefile.win32 in SVN).

The reason we don't support win32 specific makefiles any more is because
we improved the automake-based build to the point it would support
win32.  So we want to support win32 make, just not via a redundant make
system which quickly gets out of date because it is not used regularly
in the development of the binding.

Congrats on the progress.  The main "extraordinary" things you want to
keep in mind while building win64 assemblies are the following:

You will need to have a -define:WIN64LONGS in your generator build.
That is the "platform-specific" piece of the assembly build which is
needed to adapt to win64 longs not being the same size as a pointer as
on other 64 bit platforms.  If you didn't define that in your generator
build, you will need to regenerate the sources for your assemblies once
it's been rebuilt.

The other piece is the post-processing step which is performed by
gapi-cdecl-insert.  This piece could be tricky though, because somebody
already reported the existing tool does not work on the .Net 2.0 SDK
tools, and you mentioned that there isn't a 1.X SDK for win64.  The
purpose of the tool is to convert GLib.CDeclCallbackAttributes into the
IL necessary to identify callback delegates as CDECL calling convention,
something which is not possibly by adding standard attributes in .Net
1.0.  Since we generate .Net 1.x compatible code in GAPI, we can't use
the 2.0 attribute to do this, so we have to disassembly the il, insert
the appropriate code, and then reassemble the assembly.

My suspicion is that it might end up being easier to "cross-compile" the
assemblies on win32 against a 1.x SDK but add some configuration magic
to force the -define:WIN64LONGS bit.  The resulting assemblies should
then be copy deployable to win64.

Mike