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

[Miller, James V (GE, Research)]

The DynamicLoader in ITK predates the version that it is in itksys.

If the version in itksys works for all Macs, we should just re-implement
the version in ITK using the version in itksys.  If the APIs are similar 
enough, we can just have the ITK version subclass the itksys version.
Otherwise, we can delegate to itksys calls.

For backward compatibility, we'll need to keep the version in ITK
available.

Jim

-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Stefan Klein
Sent: Friday, July 21, 2006 5:23 AM
To: Neil Weisenfeld; insight-developers at itk.org
Cc: Steve Pieper
Subject: Re: [Insight-developers] I/O factory loading needs to beupdated
for Intel Macs/Mac OS 10.4 (easy fix)


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


_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers