From minc-development@bic.mni.mcgill.ca Wed Feb 4 03:28:41 2004 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 3 Feb 2004 22:28:41 -0500 Subject: [MINC-development] micopy_all_var_values dies if non-standard variables are present in MINC files In-Reply-To: <79612804-4DCA-11D8-94C1-000A95A69FCE@nmr.mgh.harvard.edu> Message-ID: Hi Rick, On Fri, 23 Jan 2004, Rick Hoge wrote: > For a while we've been motivated to add 'custom' variables to MINC > files to embed information about the experiment or analysis in a > convenient way. It seems though that non-standard variables prevent > some of the MINC tools from running. They shouldn't. That is one of the ideas behind minc. It should be extensible, and as long as you don't use any standard variable names, you should be okay. (One caution - I don't know if variables that are indexed by image dimensions are always handled properly by programs that change the dimensions, like mincresample.) Anyway, I tried resampling the file fileWithNewVariable.mnc and it worked fine on the SGIs in the BIC. Do you have an older version of mincresample? Can you trace the problem down? The fact that it dies without an error makes it hard to diagnose - the MINC package entry point just tells you that a NetCDF function failed when called by the minc function micopy_all_var_values, but NetCDF obviously did not report the error as it should have. Are you certain that you have not simply run out of disk space (or quota)? NetCDF does have a habit of swallowing that sort of error. You could try compiling a debugging version of mincresample and trace it to find out where the problem occurs. Are you using NetCDF 3.5? I think that it does a better job of reporting errors than 3.2. The only comment that I would have about your file is that you do not need to have the dimension variables (xspace, etc) indexed by anything if the spacing is regular. If you are not going to fill in the information, then you should not have the indexing. Right now, the information is contradictory and so your file is strictly speaking not valid. For the imagemin/max variables, you do not need to have them indexed by zspace if you are going to scale all of the images the same way. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Wed Feb 4 03:32:35 2004 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Tue, 3 Feb 2004 22:32:35 -0500 Subject: [MINC-development] micopy_all_var_values dies if non-standard variables are present in MINC files In-Reply-To: References: Message-ID: Thanks a lot for the suggestion - it turns out I did have an old (but not that old) version of the minc libraries. These files work fine with the current version. Also appreciate the info on the dimension vars - this has always been a bit mysterious to me but is making more sense... Rick On Feb 3, 2004, at 10:28 PM, Peter NEELIN wrote: > Hi Rick, > > On Fri, 23 Jan 2004, Rick Hoge wrote: > >> For a while we've been motivated to add 'custom' variables to MINC >> files to embed information about the experiment or analysis in a >> convenient way. It seems though that non-standard variables prevent >> some of the MINC tools from running. > > They shouldn't. That is one of the ideas behind minc. It should be > extensible, and as long as you don't use any standard variable names, > you > should be okay. (One caution - I don't know if variables that are > indexed > by image dimensions are always handled properly by programs that change > the dimensions, like mincresample.) > > Anyway, I tried resampling the file fileWithNewVariable.mnc and it > worked > fine on the SGIs in the BIC. Do you have an older version of > mincresample? > Can you trace the problem down? The fact that it dies without an error > makes it hard to diagnose - the MINC package entry point just tells you > that a NetCDF function failed when called by the minc function > micopy_all_var_values, but NetCDF obviously did not report the error > as it > should have. Are you certain that you have not simply run out of disk > space (or quota)? NetCDF does have a habit of swallowing that sort of > error. > > You could try compiling a debugging version of mincresample and trace > it > to find out where the problem occurs. > > Are you using NetCDF 3.5? I think that it does a better job of > reporting > errors than 3.2. > > The only comment that I would have about your file is that you do not > need > to have the dimension variables (xspace, etc) indexed by anything if > the > spacing is regular. If you are not going to fill in the information, > then > you should not have the indexing. Right now, the information is > contradictory and so your file is strictly speaking not valid. > > For the imagemin/max variables, you do not need to have them indexed by > zspace if you are going to scale all of the images the same way. > > Peter > ---- > Peter Neelin (neelin@bic.mni.mcgill.ca) > > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Fri Feb 6 23:00:42 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Fri, 6 Feb 2004 18:00:42 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: <323E7FC6-49CE-11D8-912C-000A95DBBFD8@bic.mni.mcgill.ca>; from jason@bic.mni.mcgill.ca on Sun, Jan 18, 2004 at 10:51:36AM -0500 References: <20040116142346.E29903@gate.nmr.mgh.harvard.edu> <323E7FC6-49CE-11D8-912C-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: <20040206180042.A5579@gate.nmr.mgh.harvard.edu> hmm. ok, i downloaded the new dist, and added flat_namespace to my flags. but that doesn't seem to be it: gcc -I/Users/nmrroot/dev/include -I/usr/pubsw/include -I/Users/nmrroot/dev/include -I/usr/pubsw/include -g -DDEBUG -DDarwin -flat_namespace -DDECLARE_PROGNAME -c -o fsgdf.o fsgdf.c gcc -dynamiclib fsgdf.o fsgdf_wrap.o -L/Users/nmrroot/dev/lib/Darwin -L/usr/pubsw/lib -lm -lutils -lunix -lhipsstubs -limage -lutils -lrgb -ltiff -ljpeg -lz -ldicom -lvolume_io -lnetcdf -lminc -ltk8.3 -ltcl8.3 -lBLT -o libtclfsgdf.dylib ld: warning prebinding disabled because dependent library: /sw/lib/libtiff.3.dylib is not prebound ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_call_depth (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_trash_var (size 4) /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common _cdf_routine_name (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_callers_ncopts (size 4) /usr/bin/libtool: internal link edit command failed make: *** [tcl] Error 1 ...any ideas? thanks, --vicka On Sun, Jan 18, 2004 at 10:51:36AM -0500, Jason Lerch wrote: > > On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: > > > hi -- i've been trying to build freesurfer on an osx 10.3 laptop. i > > am using > > the minc 1.2 cd from the workshop, and am running into some errors: > > > > building libfsgdf stuff > > /usr/bin/libtool: internal link edit command failed > > ld: warning prebinding disabled because dependent library: > > /sw/lib/libtiff.3.dylib is not prebound > > ld: common symbols not allowed with MH_DYLIB output format with the > > -multi_module option > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > _minc_call_depth (size 4) > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > _minc_trash_var (size 4) > > /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > > _cdf_routine_name (size 4) > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > _minc_callers_ncopts (size 4) > > gmake[2]: *** [tcl] Error 1 > > > > > > any ideas? > > Might be the OSX namespace issue. Try > setenv CC 'gcc -flat_namespace' > (or the same for CXX if you are using c++). > > No idea if this is your problem, but it is worh a try. > > > also, any sign of the bugfixes from awhile back...? > > > Working on it as I write this. > > Jason > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Wed Feb 11 03:23:31 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 10 Feb 2004 22:23:31 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: <20040206180042.A5579@gate.nmr.mgh.harvard.edu> References: <20040116142346.E29903@gate.nmr.mgh.harvard.edu> <323E7FC6-49CE-11D8-912C-000A95DBBFD8@bic.mni.mcgill.ca> <20040206180042.A5579@gate.nmr.mgh.harvard.edu> Message-ID: The only thing which jumps out at me - though it might not make a difference - is the order that you link the libraries. -lnetcdf should come after -lminc. Again, don't know if this will make a difference ... Jason On Feb 6, 2004, at 6:00 PM, Vicka Corey wrote: > hmm. ok, i downloaded the new dist, and added flat_namespace to my > flags. > but that doesn't seem to be it: > > gcc -I/Users/nmrroot/dev/include -I/usr/pubsw/include > -I/Users/nmrroot/dev/include -I/usr/pubsw/include -g -DDEBUG -DDarwin > -flat_namespace -DDECLARE_PROGNAME -c -o fsgdf.o fsgdf.c > gcc -dynamiclib fsgdf.o fsgdf_wrap.o -L/Users/nmrroot/dev/lib/Darwin > -L/usr/pubsw/lib -lm -lutils -lunix -lhipsstubs -limage -lutils -lrgb > -ltiff -ljpeg -lz -ldicom -lvolume_io -lnetcdf -lminc -ltk8.3 -ltcl8.3 > -lBLT -o libtclfsgdf.dylib > ld: warning prebinding disabled because dependent library: > /sw/lib/libtiff.3.dylib is not prebound > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_call_depth (size 4) > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_trash_var (size 4) > /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > _cdf_routine_name (size 4) > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_callers_ncopts (size 4) > /usr/bin/libtool: internal link edit command failed > make: *** [tcl] Error 1 > > ...any ideas? > > thanks, > --vicka > > On Sun, Jan 18, 2004 at 10:51:36AM -0500, Jason Lerch wrote: >> >> On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: >> >>> hi -- i've been trying to build freesurfer on an osx 10.3 laptop. i >>> am using >>> the minc 1.2 cd from the workshop, and am running into some errors: >>> >>> building libfsgdf stuff >>> /usr/bin/libtool: internal link edit command failed >>> ld: warning prebinding disabled because dependent library: >>> /sw/lib/libtiff.3.dylib is not prebound >>> ld: common symbols not allowed with MH_DYLIB output format with the >>> -multi_module option >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>> _minc_call_depth (size 4) >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>> _minc_trash_var (size 4) >>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common >>> _cdf_routine_name (size 4) >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>> _minc_callers_ncopts (size 4) >>> gmake[2]: *** [tcl] Error 1 >>> >>> >>> any ideas? >> >> Might be the OSX namespace issue. Try >> setenv CC 'gcc -flat_namespace' >> (or the same for CXX if you are using c++). >> >> No idea if this is your problem, but it is worh a try. >> >>> also, any sign of the bugfixes from awhile back...? >>> >> Working on it as I write this. >> >> Jason >> >> _______________________________________________ >> MINC-development mailing list >> MINC-development@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Fri Feb 13 16:45:03 2004 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 13 Feb 2004 10:45:03 -0600 Subject: [MINC-development] [zhong_xue@yahoo.com: Questions about N3 installation.] Message-ID: <20040213164503.GC8906@sickkids.ca> I received this request for help with N3. Has anyone seen this error message before? I'm not sure why sed would fail in the manner described. John ----- Forwarded message from Xue Zhong ----- X-Sieve: cmu-sieve 2.0 Date: Thu, 12 Feb 2004 16:26:09 -0800 (PST) From: Xue Zhong Subject: Questions about N3 installation. To: jgsled@bic.mni.mcgill.ca Dear Sir, I am installing the N3, however, for N3 or N3-1.07 I failed in difference cases. For N3: I got something wrong in the file Make_Rules mv blas.a ../../lib/libblas.a mv lapack.a ../../lib/liblapack.a mv F2CLIBS/libF77.a ../../lib/libF77.a (cd src; make) make 'TARGET=default' 'SUBDIRS=Base/src MincProg Classify ClassStatistics Diffuse Estimate EvaluateField ExtractTag Inormalize NUcorrect Perl Perl-aitrans SharpenHist SplineSmooth VolumeHist VolumeSplit VolumeStats' subdirs umask 002; Making default in Base/src make: file `../../Make_rules' line 30: Must be a separator (: or ::) for rules (bu39) make: file `../../Make_rules' line 32: Syntax error *** Error code 1 (bu21) *** Error code 1 (bu21) *** Error code 1 (bu21) For N3-1.07, I got something wrong when red < ...: /usr/freeware/bin/c++ -O -DNDEBUG -L/sbia/home/zxue/mni/lib -o volume_hist src/VolumeHist/minchist.o src/VolumeHist/DHistogram.o src/VolumeHist/WHistogram.o src/VolumeHist/args.o libmincprog.a -lvolume_io -lminc -lnetcdf -lm -lEBTKS -lm sed < `test -f '' || echo './'` -e 's/xVERSIONx/1.07/g' -e 's/xLONG_VERSIONx/Package MNI N3, version 1.07, compiled by zxue@athena1 (mips-sgi-irix6.5) on 2004-02-12 at 19:34:45/g' -e 's,xPERLx,/usr/freeware/bin/perl,g' -e 's,xINCDIRx,,g' > nu_evaluate sed: read error on {standard input}: Is a directory *** Error code 4 (bu21) Would you help me to figure out what is wrong here? Thanks a lot. Z XUE __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ----- End forwarded message ----- From minc-development@bic.mni.mcgill.ca Fri Feb 13 16:53:04 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 13 Feb 2004 11:53:04 -0500 Subject: [MINC-development] [zhong_xue@yahoo.com: Questions about N3 installation.] In-Reply-To: <20040213164503.GC8906@sickkids.ca> Message-ID: On Fri, 13 Feb 2004, John G. Sled wrote: > I received this request for help with N3. Has anyone seen this > error message before? I'm not sure why sed would fail in the > manner described. I have seen these errors (when compiling on IRIX) when the irix make is used as opposed to GNU make, gmake on irix if you use the freeware .tardist. In other words I don't think it a problem with sed, sed it merely being fed the wrong karma by IRIX make. > Making default in Base/src > make: file `../../Make_rules' line 30: Must be a > separator (: or ::) for rules (bu39) > make: file `../../Make_rules' line 32: Syntax error > *** Error code 1 (bu21) -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From minc-development@bic.mni.mcgill.ca Mon Feb 16 20:51:21 2004 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 16 Feb 2004 15:51:21 -0500 Subject: [MINC-development] Latest MINC 2.0 API documentation Message-ID: The latest MINC 2.0 API document is now available at: http://www.bic.mni.mcgill.ca/software/minc2/api_doc/index.html Comments and questions are encouraged, please direct them to me or to the list. -bert From minc-development@bic.mni.mcgill.ca Mon Feb 16 21:15:46 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 16 Feb 2004 16:15:46 -0500 Subject: [MINC-development] Latest MINC 2.0 API documentation In-Reply-To: Message-ID: On Mon, 16 Feb 2004, Robert VINCENT wrote: > The latest MINC 2.0 API document is now available at: > http://www.bic.mni.mcgill.ca/software/minc2/api_doc/index.html > > Comments and questions are encouraged, please direct them to me or to the > list. What's the array_length argument do in miset_real_value? I can guess but am unsure. Also are there any plans to support a "getting voxels for dummies" type function? (that doesn't require setting up a location[] array with indicies and the likes?) ie: value = miget_real_value_3D(volume, x, y, z); ? The current implementation whilst nice and general isn't that easy for newbies to grok IMHO. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From minc-development@bic.mni.mcgill.ca Mon Feb 16 21:46:19 2004 From: minc-development@bic.mni.mcgill.ca (Leila Baghdadi) Date: Mon, 16 Feb 2004 16:46:19 -0500 (EST) Subject: [MINC-development] Latest MINC 2.0 API documentation In-Reply-To: Message-ID: Andrew The answer to your first question: we just decided from the beginning to always pass the array length (size) along with the array whose bounds are not specified. If you check other functions in the API, you will see similar structure. As for getting voxels for dummies, I can not recall if we had any plans, perhaps Bert or John can correct me if otherwise but I will add your suggestion to the "to discuss list". Leila On Mon, 16 Feb 2004, Andrew Janke wrote: > On Mon, 16 Feb 2004, Robert VINCENT wrote: > > > The latest MINC 2.0 API document is now available at: > > http://www.bic.mni.mcgill.ca/software/minc2/api_doc/index.html > > > > Comments and questions are encouraged, please direct them to me or to the > > list. > > What's the array_length argument do in miset_real_value? I can guess but am > unsure. > > Also are there any plans to support a "getting voxels for dummies" type > function? (that doesn't require setting up a location[] array with indicies and > the likes?) > > ie: > > value = miget_real_value_3D(volume, x, y, z); > > ? The current implementation whilst nice and general isn't that easy for > newbies to grok IMHO. > > > -- > Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) > Australia->University of Queensland->Centre for Magnetic Resonance > W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581 > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > From minc-development@bic.mni.mcgill.ca Mon Feb 16 23:23:45 2004 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Mon, 16 Feb 2004 17:23:45 -0600 Subject: [MINC-development] Latest MINC 2.0 API documentation In-Reply-To: References: Message-ID: <20040216232345.GA20232@sickkids.ca> > What's the array_length argument do in miset_real_value? I can guess but am > unsure. > > Also are there any plans to support a "getting voxels for dummies" type > function? (that doesn't require setting up a location[] array with indicies and > the likes?) > > ie: > > value = miget_real_value_3D(volume, x, y, z); > > ? The current implementation whilst nice and general isn't that easy for > newbies to grok IMHO. > That comment is just SO three dimensional ;) Actually, I had envisioned that miget_real_value would be little used with most programs favouring the miget_real_value_hyperslab function instead. Any thoughts on how to make these hyperslab functions easier to use would be appreciated. John From minc-development@bic.mni.mcgill.ca Mon Feb 16 22:35:40 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 16 Feb 2004 17:35:40 -0500 Subject: [MINC-development] Latest MINC 2.0 API documentation In-Reply-To: <20040216232345.GA20232@sickkids.ca> Message-ID: On Mon, 16 Feb 2004, John G. Sled wrote: > > value = miget_real_value_3D(volume, x, y, z); > > > > ? The current implementation whilst nice and general isn't that easy for > > newbies to grok IMHO. > > That comment is just SO three dimensional ;) Actually, I had > envisioned that miget_real_value would be little used with most > programs favouring the miget_real_value_hyperslab function instead. :) we can hope! I think a lot of people will stil be stuck in the for for for get_vox_val(x, y, z) type logic for a while. And also, what about random and pseudo random access? If the user really is going through using a hyperslab (in most likely a nive defined order) just use voxel_loop! :) > Any thoughts on how to make these hyperslab functions easier to use > would be appreciated. Orright, they look pretty easy to follow, my first question (on both hyperslab and miget_real_value() is: In both the voxel_offsets[] and sizes[] arrays, what are the indicies? The file dimension order? or "std ordering" ie: zyx? myself I'd prefer both to be supported (for various purposes) but realise this is a difficult ask. I think however this is what you are trying to do with miset_dimension_apparent_voxel_order() no? a From minc-development@bic.mni.mcgill.ca Mon Feb 16 22:42:55 2004 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 16 Feb 2004 17:42:55 -0500 Subject: [MINC-development] Latest MINC 2.0 API documentation In-Reply-To: Message-ID: Hi, The hyperslab functions return data in either the "physical" or "apparent" dimension ordering, depending on whether miset_apparent_dimension_order() has been called. Data will be reshuffled accordingly if the "apparent" order is different from the "physical" order. The logical directions of the dimensions can also be specified by calling miset_dimension_apparent_voxel_order(). -bert On Mon, 16 Feb 2004, Andrew Janke wrote: > On Mon, 16 Feb 2004, John G. Sled wrote: > > > > value = miget_real_value_3D(volume, x, y, z); > > > > > > ? The current implementation whilst nice and general isn't that easy for > > > newbies to grok IMHO. > > > > That comment is just SO three dimensional ;) Actually, I had > > envisioned that miget_real_value would be little used with most > > programs favouring the miget_real_value_hyperslab function instead. > > :) we can hope! I think a lot of people will stil be stuck in the > > for > for > for > get_vox_val(x, y, z) > > type logic for a while. And also, what about random and pseudo random access? > If the user really is going through using a hyperslab (in most likely a nive > defined order) just use voxel_loop! :) > > > Any thoughts on how to make these hyperslab functions easier to use > > would be appreciated. > > Orright, they look pretty easy to follow, my first question (on both hyperslab > and miget_real_value() is: > > In both the voxel_offsets[] and sizes[] arrays, what are the indicies? The file > dimension order? or "std ordering" ie: zyx? > > myself I'd prefer both to be supported (for various purposes) but realise this > is a difficult ask. I think however this is what you are trying to do with > miset_dimension_apparent_voxel_order() no? > > > a > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Tue Feb 17 19:15:13 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 17 Feb 2004 14:15:13 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: ; from kteich@nmr.mgh.harvard.edu on Wed, Feb 11, 2004 at 01:37:41PM -0500 References: Message-ID: <20040217141513.Q9780@gate.nmr.mgh.harvard.edu> (taking this back to minc-development....) i think the problem is something i talked about way way long ago, which is the need to build the osx minc/netcdf libraries with -fno-common: (from feb 2003) Today I set out to link Freesurfer with the 1.1 libminc.a, and it was not happy when I wanted to make dynamic libraries: ld: common symbols not allowed with MH_DYLIB output format ld: common symbols not allowed with MH_DYLIB output format /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_call_depth (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_trash_var (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_callers_ncopts (size 4) /usr/bin/libtool: internal link edit command failed I added -fno-common to CFLAGS in the minc Makefile, which seems to have fixed it. kevin, there is a source distro of minc on their site, but i am trying to use the distributed os x build (so that we don't end up maintaining a separate one). is the current os x version being built with -fno-common? if not can it be? thanks --vicka On Wed, Feb 11, 2004 at 01:37:41PM -0500, Kevin Teich wrote: > > The only thing which jumps out at me - though it might not make a > > difference - is the order that you link the libraries. -lnetcdf should > > come after -lminc. Again, don't know if this will make a difference ... > > should this be added to flags for compilation of libminc and libnetcdf, or > for the linking of the dynamic library that uses them? i tried the latter > and it doesn't help. > > (i'm only emailing you on this because i have no idea if minc or netcdf is > distributed as source, so maybe this is a really stupid question.) > > > > > > Jason > > > > On Feb 6, 2004, at 6:00 PM, Vicka Corey wrote: > > > > > hmm. ok, i downloaded the new dist, and added flat_namespace to my > > > flags. > > > but that doesn't seem to be it: > > > > > > gcc -I/Users/nmrroot/dev/include -I/usr/pubsw/include > > > -I/Users/nmrroot/dev/include -I/usr/pubsw/include -g -DDEBUG -DDarwin > > > -flat_namespace -DDECLARE_PROGNAME -c -o fsgdf.o fsgdf.c > > > gcc -dynamiclib fsgdf.o fsgdf_wrap.o -L/Users/nmrroot/dev/lib/Darwin > > > -L/usr/pubsw/lib -lm -lutils -lunix -lhipsstubs -limage -lutils -lrgb > > > -ltiff -ljpeg -lz -ldicom -lvolume_io -lnetcdf -lminc -ltk8.3 -ltcl8.3 > > > -lBLT -o libtclfsgdf.dylib > > > ld: warning prebinding disabled because dependent library: > > > /sw/lib/libtiff.3.dylib is not prebound > > > ld: common symbols not allowed with MH_DYLIB output format with the > > > -multi_module option > > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > > _minc_call_depth (size 4) > > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > > _minc_trash_var (size 4) > > > /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > > > _cdf_routine_name (size 4) > > > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > > _minc_callers_ncopts (size 4) > > > /usr/bin/libtool: internal link edit command failed > > > make: *** [tcl] Error 1 > > > > > > ...any ideas? > > > > > > thanks, > > > --vicka > > > > > > On Sun, Jan 18, 2004 at 10:51:36AM -0500, Jason Lerch wrote: > > >> > > >> On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: > > >> > > >>> hi -- i've been trying to build freesurfer on an osx 10.3 laptop. i > > >>> am using > > >>> the minc 1.2 cd from the workshop, and am running into some errors: > > >>> > > >>> building libfsgdf stuff > > >>> /usr/bin/libtool: internal link edit command failed > > >>> ld: warning prebinding disabled because dependent library: > > >>> /sw/lib/libtiff.3.dylib is not prebound > > >>> ld: common symbols not allowed with MH_DYLIB output format with the > > >>> -multi_module option > > >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > >>> _minc_call_depth (size 4) > > >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > >>> _minc_trash_var (size 4) > > >>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > > >>> _cdf_routine_name (size 4) > > >>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > > >>> _minc_callers_ncopts (size 4) > > >>> gmake[2]: *** [tcl] Error 1 > > >>> > > >>> > > >>> any ideas? > > >> > > >> Might be the OSX namespace issue. Try > > >> setenv CC 'gcc -flat_namespace' > > >> (or the same for CXX if you are using c++). > > >> > > >> No idea if this is your problem, but it is worh a try. > > >> > > >>> also, any sign of the bugfixes from awhile back...? > > >>> > > >> Working on it as I write this. > > >> > > >> Jason > > >> > > >> _______________________________________________ > > >> MINC-development mailing list > > >> MINC-development@bic.mni.mcgill.ca > > >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > _______________________________________________ > > > MINC-development mailing list > > > MINC-development@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > > -- > Kevin Teich > > > From minc-development@bic.mni.mcgill.ca Tue Feb 17 19:19:41 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 17 Feb 2004 14:19:41 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: <20040217141513.Q9780@gate.nmr.mgh.harvard.edu> References: <20040217141513.Q9780@gate.nmr.mgh.harvard.edu> Message-ID: <3C3AAD2D-617E-11D8-9770-000A95DBBFD8@bic.mni.mcgill.ca> > > is the current os x version being built with -fno-common? if not can > it be? No, it is not currently being built with -fno-common, and yes, it certainly can be built with that option (assuming that nothing else breaks as a result, of course, though I see no reason why that should happen). Ah, I can barely await the joys of rebuilding the os x minc distro yet again ;-) Jason > > thanks > --vicka > > On Wed, Feb 11, 2004 at 01:37:41PM -0500, Kevin Teich wrote: >>> The only thing which jumps out at me - though it might not make a >>> difference - is the order that you link the libraries. -lnetcdf >>> should >>> come after -lminc. Again, don't know if this will make a difference >>> ... >> >> should this be added to flags for compilation of libminc and >> libnetcdf, or >> for the linking of the dynamic library that uses them? i tried the >> latter >> and it doesn't help. >> >> (i'm only emailing you on this because i have no idea if minc or >> netcdf is >> distributed as source, so maybe this is a really stupid question.) >> >> >>> >>> Jason >>> >>> On Feb 6, 2004, at 6:00 PM, Vicka Corey wrote: >>> >>>> hmm. ok, i downloaded the new dist, and added flat_namespace to my >>>> flags. >>>> but that doesn't seem to be it: >>>> >>>> gcc -I/Users/nmrroot/dev/include -I/usr/pubsw/include >>>> -I/Users/nmrroot/dev/include -I/usr/pubsw/include -g -DDEBUG >>>> -DDarwin >>>> -flat_namespace -DDECLARE_PROGNAME -c -o fsgdf.o fsgdf.c >>>> gcc -dynamiclib fsgdf.o fsgdf_wrap.o -L/Users/nmrroot/dev/lib/Darwin >>>> -L/usr/pubsw/lib -lm -lutils -lunix -lhipsstubs -limage -lutils >>>> -lrgb >>>> -ltiff -ljpeg -lz -ldicom -lvolume_io -lnetcdf -lminc -ltk8.3 >>>> -ltcl8.3 >>>> -lBLT -o libtclfsgdf.dylib >>>> ld: warning prebinding disabled because dependent library: >>>> /sw/lib/libtiff.3.dylib is not prebound >>>> ld: common symbols not allowed with MH_DYLIB output format with the >>>> -multi_module option >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>> _minc_call_depth (size 4) >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>> _minc_trash_var (size 4) >>>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common >>>> _cdf_routine_name (size 4) >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>> _minc_callers_ncopts (size 4) >>>> /usr/bin/libtool: internal link edit command failed >>>> make: *** [tcl] Error 1 >>>> >>>> ...any ideas? >>>> >>>> thanks, >>>> --vicka >>>> >>>> On Sun, Jan 18, 2004 at 10:51:36AM -0500, Jason Lerch wrote: >>>>> >>>>> On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: >>>>> >>>>>> hi -- i've been trying to build freesurfer on an osx 10.3 laptop. >>>>>> i >>>>>> am using >>>>>> the minc 1.2 cd from the workshop, and am running into some >>>>>> errors: >>>>>> >>>>>> building libfsgdf stuff >>>>>> /usr/bin/libtool: internal link edit command failed >>>>>> ld: warning prebinding disabled because dependent library: >>>>>> /sw/lib/libtiff.3.dylib is not prebound >>>>>> ld: common symbols not allowed with MH_DYLIB output format with >>>>>> the >>>>>> -multi_module option >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>>>> _minc_call_depth (size 4) >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>>>> _minc_trash_var (size 4) >>>>>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common >>>>>> _cdf_routine_name (size 4) >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common >>>>>> _minc_callers_ncopts (size 4) >>>>>> gmake[2]: *** [tcl] Error 1 >>>>>> >>>>>> >>>>>> any ideas? >>>>> >>>>> Might be the OSX namespace issue. Try >>>>> setenv CC 'gcc -flat_namespace' >>>>> (or the same for CXX if you are using c++). >>>>> >>>>> No idea if this is your problem, but it is worh a try. >>>>> >>>>>> also, any sign of the bugfixes from awhile back...? >>>>>> >>>>> Working on it as I write this. >>>>> >>>>> Jason >>>>> >>>>> _______________________________________________ >>>>> MINC-development mailing list >>>>> MINC-development@bic.mni.mcgill.ca >>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >>>> _______________________________________________ >>>> MINC-development mailing list >>>> MINC-development@bic.mni.mcgill.ca >>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >>> >> >> -- >> Kevin Teich >> >> >> > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Tue Feb 17 19:22:47 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 17 Feb 2004 14:22:47 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: <3C3AAD2D-617E-11D8-9770-000A95DBBFD8@bic.mni.mcgill.ca>; from jason@bic.mni.mcgill.ca on Tue, Feb 17, 2004 at 02:19:41PM -0500 References: <20040217141513.Q9780@gate.nmr.mgh.harvard.edu> <3C3AAD2D-617E-11D8-9770-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: <20040217142247.R9780@gate.nmr.mgh.harvard.edu> yes, please, would y'all do that? i added it to our local copy of the source last time, but obviously this isn't the most sustainable option.... thanks, --vicka On Tue, Feb 17, 2004 at 02:19:41PM -0500, Jason Lerch wrote: > > > > is the current os x version being built with -fno-common? if not can > > it be? > > No, it is not currently being built with -fno-common, and yes, it > certainly can be built with that option (assuming that nothing else > breaks as a result, of course, though I see no reason why that should > happen). > > Ah, I can barely await the joys of rebuilding the os x minc distro yet > again ;-) > > Jason > > > > > thanks > > --vicka > > > > On Wed, Feb 11, 2004 at 01:37:41PM -0500, Kevin Teich wrote: > >>> The only thing which jumps out at me - though it might not make a > >>> difference - is the order that you link the libraries. -lnetcdf > >>> should > >>> come after -lminc. Again, don't know if this will make a difference > >>> ... > >> > >> should this be added to flags for compilation of libminc and > >> libnetcdf, or > >> for the linking of the dynamic library that uses them? i tried the > >> latter > >> and it doesn't help. > >> > >> (i'm only emailing you on this because i have no idea if minc or > >> netcdf is > >> distributed as source, so maybe this is a really stupid question.) > >> > >> > >>> > >>> Jason > >>> > >>> On Feb 6, 2004, at 6:00 PM, Vicka Corey wrote: > >>> > >>>> hmm. ok, i downloaded the new dist, and added flat_namespace to my > >>>> flags. > >>>> but that doesn't seem to be it: > >>>> > >>>> gcc -I/Users/nmrroot/dev/include -I/usr/pubsw/include > >>>> -I/Users/nmrroot/dev/include -I/usr/pubsw/include -g -DDEBUG > >>>> -DDarwin > >>>> -flat_namespace -DDECLARE_PROGNAME -c -o fsgdf.o fsgdf.c > >>>> gcc -dynamiclib fsgdf.o fsgdf_wrap.o -L/Users/nmrroot/dev/lib/Darwin > >>>> -L/usr/pubsw/lib -lm -lutils -lunix -lhipsstubs -limage -lutils > >>>> -lrgb > >>>> -ltiff -ljpeg -lz -ldicom -lvolume_io -lnetcdf -lminc -ltk8.3 > >>>> -ltcl8.3 > >>>> -lBLT -o libtclfsgdf.dylib > >>>> ld: warning prebinding disabled because dependent library: > >>>> /sw/lib/libtiff.3.dylib is not prebound > >>>> ld: common symbols not allowed with MH_DYLIB output format with the > >>>> -multi_module option > >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>> _minc_call_depth (size 4) > >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>> _minc_trash_var (size 4) > >>>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > >>>> _cdf_routine_name (size 4) > >>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>> _minc_callers_ncopts (size 4) > >>>> /usr/bin/libtool: internal link edit command failed > >>>> make: *** [tcl] Error 1 > >>>> > >>>> ...any ideas? > >>>> > >>>> thanks, > >>>> --vicka > >>>> > >>>> On Sun, Jan 18, 2004 at 10:51:36AM -0500, Jason Lerch wrote: > >>>>> > >>>>> On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: > >>>>> > >>>>>> hi -- i've been trying to build freesurfer on an osx 10.3 laptop. > >>>>>> i > >>>>>> am using > >>>>>> the minc 1.2 cd from the workshop, and am running into some > >>>>>> errors: > >>>>>> > >>>>>> building libfsgdf stuff > >>>>>> /usr/bin/libtool: internal link edit command failed > >>>>>> ld: warning prebinding disabled because dependent library: > >>>>>> /sw/lib/libtiff.3.dylib is not prebound > >>>>>> ld: common symbols not allowed with MH_DYLIB output format with > >>>>>> the > >>>>>> -multi_module option > >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>>>> _minc_call_depth (size 4) > >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>>>> _minc_trash_var (size 4) > >>>>>> /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > >>>>>> _cdf_routine_name (size 4) > >>>>>> /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > >>>>>> _minc_callers_ncopts (size 4) > >>>>>> gmake[2]: *** [tcl] Error 1 > >>>>>> > >>>>>> > >>>>>> any ideas? > >>>>> > >>>>> Might be the OSX namespace issue. Try > >>>>> setenv CC 'gcc -flat_namespace' > >>>>> (or the same for CXX if you are using c++). > >>>>> > >>>>> No idea if this is your problem, but it is worh a try. > >>>>> > >>>>>> also, any sign of the bugfixes from awhile back...? > >>>>>> > >>>>> Working on it as I write this. > >>>>> > >>>>> Jason > >>>>> > >>>>> _______________________________________________ > >>>>> MINC-development mailing list > >>>>> MINC-development@bic.mni.mcgill.ca > >>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > >>>> _______________________________________________ > >>>> MINC-development mailing list > >>>> MINC-development@bic.mni.mcgill.ca > >>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > >>> > >> > >> -- > >> Kevin Teich > >> > >> > >> > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development