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

[David Makovský (Yakeen)]

Hi,

Mike Kestner píše v St 17. 09. 2008 v 12:11 -0500:
> 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.

I think there is no need for doing this cdecl magic on win64 platform,
everything there is fastcall, no cdecl or stdcall is possible. I think
that these calling convention attributes are ignored on this patform. 
Cannot find any proves in .net or mono dcumentations, can someone from
mono team commit it? 

Thanks in advance,
David Makovsky

> 
> 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
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list