[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
>>      
>
>    
sizing bug reported in bugzilla: 
https://bugzilla.novell.com/show_bug.cgi?id=427192 (by me). This could 
have critical consequences and using Linux x86_64 is much safer than 
using Win64 build as .NET's long have same size as IntPtr and size_t on 
the same platform.
Regards