[Insight-users] Re: ITK Wrappers and gcc_xml

[Zachary Pincus]

Brad -

I tracked down this problem (and a related issue) just a bit ago.  
It's bizarre.

On windows, itkMultiThreader.h declares that ThreadFunctionType is  
LPTHREAD_START_ROUTINE. LPTHREAD_START_ROUTINE expands to "unsigned  
long (__stdcall *)(void*)", as described here:
http://www.massey.ac.nz/~mgwalker/misc/createthread.html .

The key bit is the __stdcall, which specifies how the function is to  
be called.

While gcc_xml "sees" the __stdcall (and provides a __stdcall__  
attribute; no idea why the trailing underscores), CableSwig doesn't  
do anything with that attribute.

Thus, CablsSwig generates code that assumes that ThreadFunctionType  
is "unsigned long (*)(void*)". But VC++ defaults to declaring  
functions __cdecl if there isn't any call type. So VC++ sees the   
typedef as "unsigned long (__cdecl *)(void*)". Since __cdecl  
functions are incompatible with __stdcall functions, the compile breaks.

This problem happens again when static constants are wrapped from a  
shared library. On windows, ITKCommon_EXPORT expands to __declspec 
(dllimport), which CableSwig ignores (I'm not sure if gcc_xml gets  
this information right; I've been using xml files that Charl  
generated for me to debug this all since I don't have a windows  
machine handy), thus generating code that can't link properly. This  
is the source of the link errors that Charl wrote to the list about  
earlier.

In sum, it looks like there are some really tricky issues with  
CableSwig and these windows-specific attributes. I'm not sure if you  
ever want to touch cableswig again, or even if you did, if fixing  
this is a good use of your time. For the interim, I'm looking into  
workarounds whereby we don't let gcc_xml see the offending  
definitions, via nasty hacked headers and #define games.

Now, I have a plan, which I might not ever get a chance to implement.  
It is to write a translator that takes gcc_xml-generated files and  
outputs SWIG files where all of the templates have been flattened, to  
feed to a regular SWIG. (Basically, a very light re-implementation of  
cable_index/CableSwig). If I get around to doing that, then it  
shouldn't be hard to get the generated SWIG file to use the correct  
things from windows.i to deal with __stdcall and __declspec 
(dllimport). The other win here is that we would get to use %extend  
and %rename and %ignore and all of the other nice, modern swig things  
that would allow e.g. iterators to be used from ITK wrappers.

Zach



On Feb 16, 2006, at 8:26 AM, Brad King wrote:

> Charl P. Botha wrote:
>> Just to make 100% sure, I added --gccxml-compiler msvc71 (which is  
>> the
>> vs.net 2003 that I use) to the GCCXML_CREATE_XML_FILE macro in
>> CreateWrapperLibrary.cmake of my WrapITK checkout and rebuilt the
>> whole thing.  I still get exactly the same errors:
>
> It was probably already using that compiler if that was the  
> compiler that built it so there is no surprise the errors remain.
>
>> c:\build\WrapITK-VS71\CommonA\wrap_ITKCommonBasePython.cxx(3833):
>> error C2664: 'itk::MultiThreader::SetMultipleMethod' : cannot convert
>> parameter 2 from 'unsigned long (__cdecl *)(void *)' to
>> 'itk::ThreadFunctionType'
>
> Do you know how ThreadFunctionType is defined for this compiler?   
> You can run the GCC-XML command line by hand and add "-E" to see  
> the preprocessed output.  It could simply be that GCC's parser  
> cannot handle what is produced by the simulated MSVC  
> preprocessing.  In that case we'll have to add some code that fixes  
> the problem using __GCCXML__ to detect when the fixes are needed.
>
> -Brad
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users