[Insight-developers] MacOS version bug in the DynamicLoaded: Fix committed to the ITK-3-0 branch.

Luis Ibanez luis.ibanez at kitware.com
Thu Nov 30 18:32:45 EST 2006 

Hi Mathieu, Neil,

Thanks for the confirmation.


The changes have now been committed to the ITK 3.0 branch.


http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/kwsys/DynamicLoader.hxx.in?r1=1.5&root=Insight&sortby=date&r2=1.5.24.1&only_with_tag=ITK-3-0
http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/kwsys/DynamicLoader.cxx?r1=1.14&root=Insight&sortby=date&r2=1.14.18.1&only_with_tag=ITK-3-0
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkDynamicLoader.h?r1=1.25&root=Insight&sortby=date&r2=1.25.2.1&only_with_tag=ITK-3-0
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkDynamicLoader.cxx?r1=1.20&root=Insight&sortby=date&r2=1.20.2.1&only_with_tag=ITK-3-0




Please let us know if you find any other issues.


    Thanks


       Luis



==========================
Neil Weisenfeld wrote:
> That appears correct, however Mathieu made the final changes, so I'm 
> leaving it up to him to say "yes"
> 
> 
> Neil
> 
> 
> Luis Ibanez wrote:
> 
>>
>> Hi All,
>>
>>
>> Thanks a lot for tracking and solving this problem.
>>
>>
>> The procedure for adding patches to a branch of ITK
>> is the following:
>>
>>
>> 1) Create a bug entry in the phpBugtracker:
>>
>>     http://public.kitware.com/Bug/index.php
>>
>>    Indicate the release number. (e.g. 3.0)
>>
>>
>> 2) Assign it to the release gatekeeper (in this cycle
>>    it is still me, but this will rotate over other
>>    developers).
>>
>>
>> 3) When possible, attach the patch file to the bug
>>    entry. The bug tracker allows you to attach files
>>    to the bug reports.
>>
>>
>>
>> I just created the bug entry for this issue,
>>
>>
>> http://public.kitware.com/Bug/bug.php?op=show&bugid=4100&pos=0
>>
>> but in the future, please feel free to create the bug
>> entry directly.
>>
>>
>> I'm assuming that what needs to be moved are the most
>> recent changes in the ITK Trunk files:
>>
>>
>>   Insight/Utilities/kwsys/DynamicLoader.hxx.in
>>   Insight/Utilities/kwsys/DynamicLoader.cxx
>>   Insight/Code/Common/itkDynamicLoader.h
>>   Insight/Code/Common/itkDynamicLoader.cxx
>>
>>
>> Is that correct ?
>>
>>
>> Please let me know,
>>
>>
>>
>>     Thanks
>>
>>
>>       Luis
>>
>>
>> BTW: It will be a good idea to setup some Nightly
>>      builds of ITK 3.0 from a Darwin machine.
>>
>>
>>
>> ============================
>> Neil Weisenfeld wrote:
>>
>>> Similary, I checked this into CVS HEAD for itkDynamicLoader.cxx:
>>>
>>> weisen at weisenmac:~/projects/itk/Insight/Code/Common
>>> [534]$ cvs commit -m "BUG: incorrect Mac OS/X version test used. 
>>> according to apple docs at: 
>>> http://developer.apple.com/qa/qa2001/qa1316.html , 
>>> MAC_OS_X_VERSION_MAX_ALLOWED is actually the current OS version by 
>>> default.  Utilities/kwsys/DynamicLoader.cxx also needs to be changed. 
>>> That was confirmed empirically -- MIN_REQUIRED shows 1010 on MacOS 
>>> 10.4 on PowerPC but MAX_ALLOWED shows 1040." itkDynamicLoader.cxx
>>> /cvsroot/Insight/Insight/Code/Common/itkDynamicLoader.cxx,v  <-- 
>>> itkDynamicLoader.cxx
>>> new revision: 1.21; previous revision: 1.20
>>>
>>>
>>> Note that fixing the kwsys version in ITK doesn't fix 
>>> itkDynamicLoader -- I'm not sure where the kwsys version gets used, 
>>> but not by the I/O factories (unless I'm missing something).
>>>
>>> So, Luis, we have changes to kwsys/DynamicLoader{.cxx,.hxx.in} and 
>>> Code/Common/itkDynamicLoader.cxx at CVS HEAD that need to be in ITK-3-0.
>>>
>>>
>>> neil
>>>
>>>
>>>
>>> Mathieu Malaterre wrote:
>>>
>>>> This should be fixed. Neil a/o Katie could you please double check.
>>>>
>>>> I do not have write access to the branch on ITK, so I am forwarding 
>>>> to Luis once somebody report the issue is solved.
>>>>
>>>>
>>>> Thanks.
>>>> Mathieu
>>>>
>>>> $ cvs ci -m"BUG: Fix problem with loading dylib on Tiger (10.4) x86. 
>>>> We need to be using the dlopen/dlclose instead of the old NSModule" 
>>>> DynamicLoader.cxx DynamicLoader.hxx.in
>>>> /cvsroot/VTK/VTK/Utilities/kwsys/DynamicLoader.cxx,v  <--  
>>>> DynamicLoader.cxx
>>>> new revision: 1.15; previous revision: 1.14
>>>> /cvsroot/VTK/VTK/Utilities/kwsys/DynamicLoader.hxx.in,v  <-- 
>>>> DynamicLoader.hxx.in
>>>> new revision: 1.6; previous revision: 1.5
>>>>
>>>>
>>>>
>>>>
>>>> Steve Pieper wrote:
>>>>
>>>>> Thanks Neil!
>>>>>
>>>>> This really should be fixed on the ITK-3-0 branch -- if so it would 
>>>>> fix the issue for slicer3.
>>>>>
>>>>> Who needs to approve such a commit?  Should we pull in Bill, Jim, 
>>>>> Luis, Stephen... ?
>>>>>
>>>>> -Steve
>>>>>
>>>>> Mathieu Malaterre wrote:
>>>>>
>>>>>> Hi Neil,
>>>>>>
>>>>>>     Thanks for investigating. I believe this test should be done 
>>>>>> at the kwsys layer to prevent anyone to have this problem in the 
>>>>>> future (indeed VTK also has a wrapper around kwsys::DynamicLoader, 
>>>>>> thus the very same problem might come back).
>>>>>>
>>>>>>     Let me do this quick patch to kwsys.
>>>>>>
>>>>>> Thanks
>>>>>> Mathieu
>>>>>>
>>>>>> Neil Weisenfeld wrote:
>>>>>>
>>>>>>> MATHIEU -- the incorrect test for MacOS version is still used in 
>>>>>>> Utilities/kwsys/DynamicLoader.cxx and presumably in CMake, also, 
>>>>>>> given comments in the CVS logs.  Here's the correct answer:
>>>>>>>
>>>>>>> Despite hours of searching yesterday, I found the answer today in 
>>>>>>> a QuickTime article:
>>>>>>>
>>>>>>> By default, MAC_OS_X_VERSION_MAX_ALLOWED is the version of Mac OS 
>>>>>>> X you are compiling on. For MacOS 10.2.x 
>>>>>>> MAC_OS_X_VERSION_MAX_ALLOWED is defined as 1020, for MacOS X 10.3 
>>>>>>> it is 1030 and so on. By using MAC_OS_X_VERSION_MAX_ALLOWED as 
>>>>>>> the way to conditionalize, you are ensuring that the bracketed 
>>>>>>> code will only compile on MacOS X 10.3 or later.
>>>>>>>
>>>>>>> http://developer.apple.com/qa/qa2001/qa1316.html
>>>>>>>
>>>>>>> I will check the change for Code/Common/itkDynamicLoader.cxx into 
>>>>>>> ITK HEAD.
>>>>>>>
>>>>>>> STEVE/KATIE: How do we make sure that it's use for Slicer3?
>>>>>>>
>>>>>>>
>>>>>>> Neil
>>>>>>>
>>>>>>>
>>>>>>> Neil Weisenfeld wrote:
>>>>>>>
>>>>>>>> Okay, here's the deal regarding the Macs.
>>>>>>>>
>>>>>>>> Apple deprecated the old module loading techniques and MacOS now 
>>>>>>>> uses the standard dlopen/dlclose.
>>>>>>>>
>>>>>>>> Right before ITK 3.0.0 was released, I added a change that 
>>>>>>>> should make the default Unix dlopen/dlclose code be used under 
>>>>>>>> MacOS >= 10.3.
>>>>>>>>
>>>>>>>> The problem is that I use the macro 
>>>>>>>> MAC_OS_X_MIN_VERSION_REQUIRED in order to determine, at compile 
>>>>>>>> time, what the OS version is.  It didn't *seem* like this was 
>>>>>>>> the correct macro based on the name, however it was used in the 
>>>>>>>> kwsys dynamic loader code, so I figured it was correct. Reading 
>>>>>>>> the header file, it's actually a macro that an application 
>>>>>>>> should *set* based on its own preferences and its default value 
>>>>>>>> changes from platform to platform and is *not* the current OS 
>>>>>>>> version.  It turns out that under 10.4, it's 10.3 on Intel Macs, 
>>>>>>>> but 10.1 on PowerPC macs.
>>>>>>>>
>>>>>>>> We need to do one of three things:
>>>>>>>>
>>>>>>>> 1. figure out what the correct macro to use is.
>>>>>>>> 2. create a new one that will be set somehow
>>>>>>>> 3. decide that ITK won't support older Mac OS/X versions where 
>>>>>>>> dlopen/dlclose does not work (maybe prior to 10.3?) and simply 
>>>>>>>> remove the old code and rely solely on #ifdef __APPLE__
>>>>>>>>
>>>>>>>> Mathieu, do you know what the correct macro is for determining 
>>>>>>>> OS versions?  I've been crawling through Apple's docs without 
>>>>>>>> luck and Google searches simply return other people having the 
>>>>>>>> same problem with no answers found.  Feel free to pass this on 
>>>>>>>> to other Mac folks or I can post it to the ITK list.
>>>>>>>>
>>>>>>>> Katie, I'm sorry that you're having problems, however this was 
>>>>>>>> going to happen anyway -- the code that's getting compiled in on 
>>>>>>>> PowerPC is what was there before I made any changes.  Also, I 
>>>>>>>> can instruct you on how to make a local change to the ITK that 
>>>>>>>> you're building in order to force the right thing to happen.
>>>>>>>>
>>>>>>>> Neil
>>>>>>>>
>>>>>>>>
>>>>>>>> Kathryn Hayes wrote:
>>>>>>>>
>>>>>>>>> I created an account for you on slicerm.  Your username is 
>>>>>>>>> 'neil' and pass
>>>>>>>>> is 'bwhspl' (please change it).  I've been building in
>>>>>>>>> /Users/slicer/Slicer3-build.  Right now I also have a build 
>>>>>>>>> going in /tmp,
>>>>>>>>> so if you could avoid rebooting, that would be great.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Katie
>>>>>>>>>
>>>>>>>>> On Tue, 28 Nov 2006 neil at bwh.harvard.edu wrote:
>>>>>>>>>
>>>>>>>>>> Sorry -- been away from e-mail reading today.  I sent another 
>>>>>>>>>> note about
>>>>>>>>>> it, however it should do the "right thing" on the powerpc.  
>>>>>>>>>> Clearly the
>>>>>>>>>> wrong code path is being compiled in as the trace shows the 
>>>>>>>>>> old code.  I
>>>>>>>>>> had asked Katie what version of ITK she was using for just 
>>>>>>>>>> this reason.
>>>>>>>>>>
>>>>>>>>>> Is there a guest account on the machine that I can log into 
>>>>>>>>>> and see why
>>>>>>>>>> it's not working?
>>>>>>>>>>
>>>>>>>>>> Either the wrong ITK is being checked out or the compiler on 
>>>>>>>>>> that machine
>>>>>>>>>> defines different symbols.  Is it OSX 10.4?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Neil
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, 28 Nov 2006, Steve Pieper wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Neil - is there something different we should be doing on 
>>>>>>>>>>> ppc?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Steve
>>>>>>>>>>>
>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>> Subject: Re: [slicer-devel] Slicer3 on darwin-ppc
>>>>>>>>>>> Date: 28 Nov 2006 16:19:34 -0500
>>>>>>>>>>> From: Mathieu Malaterre <mathieu.malaterre at kitware.com>
>>>>>>>>>>> Organization: Kitware Inc.
>>>>>>>>>>> To: Kathryn Hayes <hayes at bwh.harvard.edu>
>>>>>>>>>>> CC: slicer-devel at bwh.harvard.edu
>>>>>>>>>>> References: 
>>>>>>>>>>> <Pine.GSO.4.58.0611281230230.548 at b2-15-5.bwh.harvard.edu>
>>>>>>>>>>>
>>>>>>>>>>>> #0  0x8fe09040 in __dyld_NSLinkModule ()
>>>>>>>>>>>> #1  0x9002d44c in NSLinkModule ()
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is wrong. On 10.4 (Tiger) you should be using the 
>>>>>>>>>>> dlopen/dlclose
>>>>>>>>>>> system call and not the old one. Something is not configured 
>>>>>>>>>>> correctly.
>>>>>>>>>>> I might have some time at the end of the week to have a look 
>>>>>>>>>>> at it.
>>>>>>>>>>>
>>>>>>>>>>> -M
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> slicer-devel mailing list
>>>>>>>>>>> slicer-devel at lists.bwh.harvard.edu
>>>>>>>>>>> https://www.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

More information about the Insight-developers mailing list