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

[Jaroslav Šmíd]

David Makovský (Yakeen) wrote:
> 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
>>      
>
>    
Damn. This will not be as simple as I thought it would be ... with 
WIN64LONGS defined for generator, I get error when building gtk-sharp:
generated\GtkSharp.TextBufferSerializeFuncNative.cs(63,18): error 
CS1594: Delegate 'Gtk.TextBufferSerializeFunc' has some invalid arguments
generated\GtkSharp.TextBufferSerializeFuncNative.cs(63,196): error 
CS1503: Argument '5': cannot convert from 'out uint' to 'out ulong'

It seems there is some type problem when WIN64LONGS gets defined. I 
don't know where to fix it (maybe some *.custom, *.metadata?). Could 
this be fixed so I can finish the build? Please.

This is the part in that file:

----------------------------

         public byte NativeCallback (IntPtr register_buffer, IntPtr 
content_buffer, IntPtr start, IntPtr end, out uint length, IntPtr user_data)
         {
             try {
                 byte __ret = managed 
(GLib.Object.GetObject(register_buffer) as Gtk.TextBuffer, 
GLib.Object.GetObject(content_buffer) as Gtk.TextBuffer, 
Gtk.TextIter.New (start), Gtk.TextIter.New (end), out length);
                 if (release_on_call)
                     gch.Free ();
                 return __ret;
             } catch (Exception e) {
                 GLib.ExceptionManager.RaiseUnhandledException (e, true);
                 // NOTREACHED: Above call does not return.
                 throw e;
             }
         }