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

Claude LEPAGE claude at bic.mni.mcgill.ca
Thu Feb 24 16:28:31 EST 2011


Jim,

Are you sure about this? I believe my built is totally static for
minc, volume_io, hdf5 and netcdf. Do "otool -L minccalc" and post
the output. 

You probably got confused with our first attempt to build minc
which had hdf5 and netcdf dynamic since I had /opt/local as part
of the build path for configure.

Claude


> Hi Peter and List,
>
>    Peter, I think you might be onto something here.  The ldd
> equivalent is called otool, and I've taken a look. The latest version
> that I built with Claude links hdf5 and netcdf as dynamic -- all other
> libs are statically linked into the executable (minc, volume_io).  In
> the previous build, we had a very different configuration:
> dynamic=3D(volume_io, minc2, hdf5), all the rest linked as static
> (including netcdf). Apple seems to prefer linking dynamically, if it
> can find a dynamic lib, else it grabs the static.
>
> What would be the suggested optimal linking? hdf5 and netcdf dynamic
> and all of the mincy libs linked statically with the executable.  BTW,
> running "make check" with the latest library configuration seems to
> given me a different error. Progress?
>
> -jim
>
>
> On Thu, Feb 24, 2011 at 2:45 PM, Peter Neelin <peter.neelin at gmail.com> wrot=
> e:
> > On Thu, Feb 24, 2011 at 1:45 PM, EJ Nikelski <nikelski at bic.mni.mcgill.ca>=
>  wrote:
> >
> >> =A0 So, given the thumbs down from Peter, I looked a bit closer. As it
> >> turns out, on Snow Leopard, even after ncopts=3D0 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. =A0Funnily 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)
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
>
> -- =
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D
> Jim Nikelski, Ph.D.
> Postdoctoral Research Fellow
> Bloomfield Centre for Research in Aging
> Lady Davis Institute for Medical Research
> Sir Mortimer B. Davis - Jewish General Hospital
> McGill University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


More information about the MINC-users mailing list