[Insight-developers] SimpleITK: C# building 32 on 64
Dan Mueller
dan.muel at gmail.com
Wed Feb 1 01:13:12 EST 2012
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
On 1 February 2012 12:10, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Dan,
>
> I am CC'ing the developer list because there should probably be a better paper trail of the SimpleITK design and development and this will archive it, and enable any one else to chime as well.
>
> On Jan 31, 2012, at 4:57 PM, Dan Mueller wrote:
>
>> Hi Brad,
>>
>>> I was hoping that we could do some c# packaging for the release this week,
>>> but both the 32-bit and 64-bit on windows seems to have some issues.
>>
>> I will try to find the time to look into the issue related to building
>> 32-bit executables on a 64-bit machine.
>
> Thank's again so much for you effort on C# in SimpleITK.
>
>>
>> I just sent a gerrit review which should fix the C# example
>> compilation. With this fix, I don't see any other C# specific issues.
>> (CSharp.VotingBinary test is failing, but it is also failing for other
>> languages also, so I assume the hash has changed?). Are there any
>> other C# issues I am missing?
>
> I am testing the patch now.
>
> The VotingBinary test is failing due to un-set pixel. There is a patch to ITK to address this.
>
> Documentation for C# could be improved in a couple areas. First there should be a C# section in the Getting started guide, to help users setting up the with the binary distribution.
>
> http://www.itk.org/Wiki/ITK_Release_4/SimpleITK/GettingStarted
>
> Perhaps some additional examples could be useful too. Maybe a sub-directory which could be used as a starting ground for a C# project.
>
> Thanks,
> Brad
>
>
>>
>> If we are pressed for time, one option is to consider only packaging
>> C# for 64-bit platforms...
>>
>> Cheers, Dan (M)
>>
>> On 1 February 2012 01:47, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> Hello,
>>>
>>> When building on a 32-bit system we are running out of memory when linking.
>>> I am hopeful that if shared libraries are used this issue can be avoided.
>>>
>>> http://www.cdash.org/CDash/viewBuildError.php?buildid=1963323
>>>
>>> So I configured a win7-64-bit system to compile for the 32-bit platforms.
>>> While compiling went OK, and much faster then the 64-bit C#. At runtime all
>>> the C# tests are failing with the following error message:
>>>
>>>
>>> http://www.cdash.org/CDash/testDetails.php?test=133503767&build=1963319
>>>
>>> Running command:
>>> 'C:/d/vs10-32/SimpleITK-build/SimpleITK-build/Wrapping/CSharpBinaries/TestAddImageFilter.exe
>>> c:/d/vs10-32/SimpleITK/Testing/Data/Input/RA-Short.nrrd 2d
>>> c:/d/vs10-32/SimpleITK/Testing/Data/Input/STAPLE1.png
>>> c:/d/vs10-32/SimpleITK/Testing/Data/Input/STAPLE2.png
>>> C:/d/vs10-32/SimpleITK-build/SimpleITK-build/Testing/Temporary/CSharp-Add-2d.nrrd
>>> '
>>> ERROR: System.TypeInitializationException: The type initializer for
>>> 'itk.simple.SimpleITKPINVOKE' threw an exception. --->
>>> System.TypeInitializationException: The type initializer for
>>> 'SWIGExceptionHelper' threw an exception. ---> System.BadImageFormatExce
>>> ption: An attempt was made to load a program with an incorrect format.
>>> (Exception from HRESULT: 0x8007000B)
>>> at
>>> itk.simple.SimpleITKPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_SimpleITK(ExceptionDelegate
>>> applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate
>>> divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate,
>>> ExceptionDelegate invalidCastDelegate, ExceptionDelegate
>>> invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate
>>> nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate,
>>> ExceptionDelegate overflowDelegate, ExceptionDelegate
>>> systemExceptionDelegate)
>>> at itk.simple.SimpleITKPINVOKE.SWIGExceptionHelper..cctor()
>>> --- End of inner exception stack trace ---
>>>
>>>
>>> Any ideas?
>>>
>>> I was hoping that we could do some c# packaging for the release this week,
>>> but both the 32-bit and 64-bit on windows seems to have some issues.
>>>
>>> Thanks for you suggestions,
>>> Brad
>>>
>>> ========================================================
>>>
>>> Bradley Lowekamp
>>>
>>> Medical Science and Computing for
>>>
>>> Office of High Performance Computing and Communications
>>>
>>> National Library of Medicine
>>>
>>> blowekamp at mail.nih.gov
>>>
>>>
>>>
>>>
>
More information about the Insight-developers
mailing list