[Insight-developers] I/O factory loading needs to be updated for Intel Macs/Mac OS 10.4 (easy fix)

[Neil Weisenfeld]

Actually, it does appear as if the kwsys version of the dynamic loader 
contains some important bugfixes to uninitialized variables, incorrect 
return values, etc.  As Stefan mentioned, maybe it could be back ported 
into itk BUT if that's going to take a long time, maybe the preprocessor 
changes can be done in the short term.  Note that you'll probably have 
to include AvailabilityMacros.h if you check that Mac OS version tag.


Neil

Neil Weisenfeld wrote:
> I don't see the itksys version in my checkout (there is no itksys 
> directory),  however the current dynamic loader is both trivial in 
> implementation and works -- why change it?  All that needs to happen is 
> that the special __APPLE__ case needs to be *skipped* for the proper 
> machines in favor of the vanilla Unix implementation.
> 
> Here's the open question: is the problem all Macs with recent OS's or 
> just Intel ones.  Was the problem you experienced on a PowerPC machine 
> running a recent MacOS?
> 
> Since Intel Macs *have* to have a recent OS, the solution of changing 
> #if defined(__APPLE__)
> to
> #if defined(__APPLE__) && !defined(__i386__)
> will fix the problem for, at least, Intel machines and will not break 
> non-Intel machines.
> 
> 
> Neil
> 
> 
> 
> 
> Stefan Klein wrote:
>> Hi Neil,
>>
>> I found the same bug (or actually, somebody else, who compiled my code 
>> on a mac).
>>
>> In the itksys directory (<your-itk-binary-dir>\Utilities\itksys) you 
>> can find another DynamicLoader, which is more up-to-date and works 
>> well on new Apples (and also on old ones i guess). Its interface is 
>> almost the same, and you can include it with the following statement:
>>
>> #include <itksys/DynamicLoader.hxx>
>>
>> the class 'lives' in the itksys namespace by the way.
>>
>> Question to the ITK-gurus: Why does the itk::DynamicLoader not use the 
>> itksys::DynamicLoader internally?
>>
>> Regards,
>> Stefan.
>>
>>
>>
>> At 15:34 20/07/06, Neil Weisenfeld wrote:
>>> I'm a fairly new Mac owner and am relying on a custom I/O factory 
>>> that I've written for ITK.
>>>
>>> Currently, builds on my Intel-based MacBook Pro (OS/X 10.4.7) cause a 
>>> bus error when trying to load my custom module (but keep reading).
>>>
>>> The ITK dynamic loading stuff in Code/Common/itkDynamicLoader.cxx has 
>>> a special case for #ifdef __APPLE_.  This makes use of deprecated 
>>> functions in order to perform dynamic module loading.  Simply 
>>> disabling this special __APPLE__ case on my builds allows the normal 
>>> Unix (dlopen, etc.) code path to be compiled in and this works 
>>> correctly.
>>>
>>> If this only applies to the Intel Macs, then a quick fix is to change
>>>
>>> #if defined( __APPLE__ )
>>> to
>>> #if defined(__APPLE__) && !defined(__i386__)
>>>
>>> should do the trick, however this Apple tech note seems to indicate 
>>> that the method in use is simply deprecated (Apple says "discouraged"):
>>>
>>> http://developer.apple.com/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html 
>>>
>>>
>>> It would be nice if this were fixed in the official release for me 
>>> and the slicer branch as this breaks Slicer, too.  I guess I'm one of 
>>> a small number of people who are using loadable I/O factories.  I'm 
>>> not sure what the best fix is: are there still people running ITK on 
>>> platforms that require the older NSLinkModule stuff, etc?  Maybe we 
>>> can hear from some Mac experts in the audience.
>>>
>>>
>>> Regards,
>>> Neil
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>