[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