[Insight-developers] SimpleITK: C# building 32 on 64

[Bradley Lowekamp]

Hello,

The dashboard didn't go over smoothly. But I think I just committed the fix:

http://public.kitware.com/gitweb?p=SimpleITK.git;a=commit;h=c562e276b4c583d2616ea0664dadad40a7550c46

I'll firing off that build again to see if the issue is fix.

This patch made me look at FindCSharp.cmake, where I see the following:


unset( CSHARP_COMPILER CACHE )
unset( CSHARP_INTERPRETER CACHE )
unset( CSHARP_TYPE CACHE )
unset( CSHARP_VERSION CACHE )
unset( CSHARP_FOUND CACHE )


I am surprised to see these variables unset, as I am not sure that is normal behavior. With this configuration, it's not clear to be if these variables can be propagated from the superbuild to the SimpleITK sub-project. I'll look into this further...

Brad


On Feb 2, 2012, at 6:54 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> Hi Dan,
> 
> I was trying to test it yesterday on  a windows machine. i did a couple of thing wrong and had to rebuild. Then I ran into a problem where the Wrapping/CSharp/*.cs were included but the filter was not in this branch. So there is a make clean issue with the *.cs files in the wrapped directory that was causing me a problem.
> 
> I think I got it to build OK at the end of the day... but I need to check.
> 
> I am working on it and will add update the cmake script as sugested.
> 
> Brad
> 
> On Feb 2, 2012, at 2:32 AM, Dan Mueller wrote:
> 
>> Hi Brad,
>> 
>> Did you see my changeset addressing the SimpleITK C# 32/64-bit issue?
>>   http://review.source.kitware.com/3787
>> 
>> I think this should make it possible to create 32-bit C# assemblies on
>> a 64-bit build machine. The trick is to force CSHARP_PLATFORM=x86.
>> This can be easily done manually using the CMake GUI. Is it possible
>> to set a CMake variable automatically in your CTest script?
>> 
>> Cheers, Dan M
>> 
>> On 1 February 2012 16:43, Dan Mueller <dan.muel at gmail.com> wrote:
>>> Hi Brad,
>>> 
>>> FYI: I have a workaround for the C# issue when building 32-bit
>>> binaries on 64-bit machine. I will prepare a gerrit review.
>>> 
>>> Here is my analysis:
>>> 
>>> The link Matt sent is a little misleading: the issue is not really
>>> with SWIG, but rather with the user (us/me :D). A little education: a
>>> .NET or Mono "assembly" (assembly = dll) can be compiled for different
>>> platforms: x86, x64, or anycpu. anycpu will generate the machine code
>>> for the platform which is running the assembly on-the-fly. In a recent
>>> commit, I changed the setup so that all assemblies are always compiled
>>> for anycpu. This scheme works fine for purely managed code (managed =
>>> code compiled to the common language runtime, or -- in Java
>>> terminology -- byte code). Unfortunately, anycpu does not play nicely
>>> with p/invoke (p/invoke = the method SWIG uses to call the non-managed
>>> SimpleITK code). See here:
>>> http://msdn.microsoft.com/en-us/library/system.badimageformatexception.aspx#remarksToggle
>>> 
>>> In short: it is not possible to run an anycpu assembly with x86
>>> p/invoke dll on an x64 machine.
>>> 
>>> There are a number of options:
>>> (1) Don't run the anycpu assembly + x86 p/invoke dll on an x64 machine
>>> :D This is not really an option for us as the build machine is x64.
>>> (2) Use the corflags.exe tool to change the assembly platform.
>>> (3) Build with specific x86 or x64 flags.
>>> 
>>> I prefer option 3. To get this to work, we need to detect and/or be
>>> able to force the target platform. I will modify the C# related CMake
>>> scripts to -- as best it can -- automatically detect. A force is also
>>> required because it is not always possible to automatically detect the
>>> correct platform based on the CMake generator type i.e. if the user
>>> selects the NMake generator.
>>> 
>>> Hopefully I will have time to prepare the gerrit review later today or tomorrow.
>>> 
>>> Cheers, Dan M

========================================================
Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20120203/2fc16810/attachment.htm>