[MINC-users] minc "make check" error -- not just a Snow Leopard problem

Peter Neelin peter.neelin at gmail.com
Thu Feb 24 14:45:55 EST 2011


On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:

>   So, given the thumbs down from Peter, I looked a bit closer. As it
> turns out, on Snow Leopard, even after ncopts=0 prior to the call to
> ncvarid(), ncvarid() receives the default ncopts() value of 3 (i.e.,
> display error message and *do not return* to calling program. So the
> error return handling code is never entered.  Funnily enough, as this
> works correctly under Linux, this *does* appear to be a Snow Leopard
> problem after all.

I wondered if there might be some funkiness with dynamically-loaded
libraries in which ncopts is not truly global. Minc changes the
variable but this is not seen by ncvarid() loaded from a different
library. Could minc be defining its own ncopts? (Anyone know much
about the weirdnesses of building shared libraries in Mac OS X?)

I am assuming that we are dealing with shared libraries here - is that
true? Or is the binary statically linked? (Does Snow Leopard have an
ldd?)

Peter
-- 
Peter Neelin
(peter.neelin at gmail.com)


More information about the MINC-users mailing list