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

[Jaroslav Šmíd]

Mike Kestner wrote:
> 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
>
>    
You are doing definitely doing something wrong. My error was due to 
GtkSharp bad understanding of gsize type present in glib. gsize in glib 
is typedefed to ulong ONLY when sizeof(long) == sizeof(size_t). But on 
64bit windows, where sizeof(size_t) and sizeof(long) are different, 
gsize is defined as unsigned long long of size equal to size of pointer 
but you suppose it is the same size as long. Therefore generator should 
not generate this on Win64:
internal delegate byte TextBufferSerializeFuncNative(IntPtr 
register_buffer, IntPtr content_buffer, IntPtr start, IntPtr end, out 
uint length, IntPtr user_data);
but
internal delegate byte TextBufferSerializeFuncNative(IntPtr 
register_buffer, IntPtr content_buffer, IntPtr start, IntPtr end, out 
long length, IntPtr user_data);

because length argument in gtk_text_buffer_serialize is gsize, not long!