From a.janke at gmail.com Thu Jul 15 10:42:27 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 16 Jul 2010 00:42:27 +1000 Subject: [MINC-development] MINC, RMINC and -fPIC Message-ID: Hi all, I have had a request from the RMINC people to add -fPIC when building MINC so that they can dynamically load "stuff". I can't see this being a problem but wanted to check with others first. To achieve this, the easiest way is to just remove this: AC_DISABLE_SHARED from configure.in I have included an explanation of this from Jim, one of the RMINC people below. a --- Hi Andrew, ?... building RMINC on x86_64 fails because the RMINC shared object that gets dynamically loaded into R at run-time, is unable to link to the minc2 library. This is because under x86_64, the linker needs the minc library to be generated with position independent code ("-fPIC" compile option), prior to linking with the RMINC shared object. ?Now, shared libraries default to generating fPIC code, so linking a shared minc2 library is not a problem. ?On the other hand, when building a static minc library, fPIC is not used by default, so it needs to be added. In my testing, RMINC linked without problem to a static minc lib IFF the fPIC switch was used during the minc build. ?So, it seems to me that given that: (1) we want to release a new version of RMINC in the very near future (2) Andrew's pre-compiled binaries for 64-bit Lucid deliver only a static minc lib (3) more and more people are using 64-bit systems ... we need to have minc built with the -fPIC option, and have a new mincbundle generated that references the new minc. ?I, of course, stand ready to test. Comments? Suggestions? Deriding laughter? Cheers, -jim -- ================================= 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 From jcupitt at gmail.com Fri Jul 23 07:25:50 2010 From: jcupitt at gmail.com (jcupitt at gmail.com) Date: Fri, 23 Jul 2010 12:25:50 +0100 Subject: [MINC-development] bug in upet2mnc Message-ID: Hi, I think I've found a bug in upet2mnc. If i run the version that comes with Ubuntu Lucid (2.0.18) on an x64 machine, I get: $ upet2mnc c4.img poop.mnc Starting conversion - Input header: c4.img.hdr - Input image: c4.img - Output file: poop.mnc WARNING: Unrecognized keyword manufacturer Segmentation fault $ Looking at the source, the problem is in the message() function. It includes this code: va_start(ap, fmt); if (_verbose_flag || level != MSG_INFO) { if (level != MSG_INFO) { if (prefix_str != NULL) { fprintf(stderr, "%s", prefix_str); } vfprintf(stderr, fmt, ap); } if (prefix_str != NULL) { fprintf(stdout, "%s", prefix_str); } vfprintf(stdout, fmt, ap); } va_end(ap); So it's setting up ap once but then, for non-info messages, using it twice. One simple fix would be to put the va_start() around each vfprintf(): if (_verbose_flag || level != MSG_INFO) { if (level != MSG_INFO) { if (prefix_str != NULL) { fprintf(stderr, "%s", prefix_str); } va_start(ap, fmt); vfprintf(stderr, fmt, ap); va_end(ap); } if (prefix_str != NULL) { fprintf(stdout, "%s", prefix_str); } va_start(ap, fmt); vfprintf(stdout, fmt, ap); va_end(ap); } Which fixes the segv, phew. John From steve at sumost.ca Sat Jul 24 13:08:12 2010 From: steve at sumost.ca (Steve M. Robbins) Date: Sat, 24 Jul 2010 12:08:12 -0500 Subject: [MINC-development] MINC, RMINC and -fPIC In-Reply-To: References: Message-ID: <20100724170812.GC3633@sumost.ca> On Fri, Jul 16, 2010 at 12:42:27AM +1000, Andrew Janke wrote: > Hi all, > > I have had a request from the RMINC people to add -fPIC when building > MINC so that they can dynamically load "stuff". > > I can't see this being a problem but wanted to check with others first. > To achieve this, the easiest way is to just remove this: > > AC_DISABLE_SHARED > > from configure.in I have no objection to that change. Note, however, that all it does is specify that shared libraries are not build BY DEFAULT. With the existing package, you can still create shared libs (I do it in the Debian packages) using: ./configure --enable-shared ... > On the other hand, when building a static minc library, fPIC > is not used by default, so it needs to be added. I don't think you want -fPIC on static libs as a general rule. I can't find the reference but my recollection is that it causes a problem on some architectures. > In my testing, RMINC > linked without problem to a static minc lib IFF the fPIC switch was > used during the minc build. ?So, it seems to me that given that: > > (1) we want to release a new version of RMINC in the very near future > (2) Andrew's pre-compiled binaries for 64-bit Lucid deliver only a > static minc lib > (3) more and more people are using 64-bit systems > > ... we need to have minc built with the -fPIC option, and have a new > mincbundle generated that references the new minc. ?I, of course, > stand ready to test. Comments? Suggestions? Deriding laughter? I think that creating binary builds with --enable-shared will do the trick. However, recall that the reason AC_DISABLE_SHARED is present in configure.in is because installing a shared lib into a directory not searched by default causes naive users a lot of grief. We used to build into /usr/local/mni by default (which is not searched at runtime). Not sure what the present practice is. -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From vladimir.fonov at gmail.com Sat Jul 24 18:27:01 2010 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Sat, 24 Jul 2010 18:27:01 -0400 Subject: [MINC-development] MINC, RMINC and -fPIC In-Reply-To: <20100724170812.GC3633@sumost.ca> References: <20100724170812.GC3633@sumost.ca> Message-ID: <4C4B68B5.9090004@gmail.com> Hello, Steve M. Robbins wrote: > On Fri, Jul 16, 2010 at 12:42:27AM +1000, Andrew Janke wrote: >> I have had a request from the RMINC people to add -fPIC when building >> MINC so that they can dynamically load "stuff". how about --with-pic option for configure which is already there? -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Tue Jul 27 00:15:09 2010 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 27 Jul 2010 14:15:09 +1000 Subject: [MINC-development] MINC, RMINC and -fPIC In-Reply-To: <20100724170812.GC3633@sumost.ca> References: <20100724170812.GC3633@sumost.ca> Message-ID: >> I can't see this being a problem but wanted to check with others first. >> To achieve this, the easiest way is to just remove this: >> >> ? ?AC_DISABLE_SHARED >> >> from configure.in > > I have no objection to that change. > > Note, however, that all it does is specify that shared libraries are > not build BY DEFAULT. ?With the existing package, you can still > create shared libs (I do it in the Debian packages) using: > > ? ? ? ?./configure --enable-shared ... Sure but in this case it is all about making sure the next MINC release (2.1) is suitable for the RMINC people or else they will have to compile their own just to distribute RMINC. So perhaps then it is best to leave things are they are and just use --enable-shared --with-pic when making binaries? a From a.janke at gmail.com Tue Jul 27 02:40:35 2010 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 27 Jul 2010 16:40:35 +1000 Subject: [MINC-development] bug in upet2mnc In-Reply-To: References: Message-ID: Hi John, On Fri, Jul 23, 2010 at 21:25, wrote: > Hi, I think I've found a bug in upet2mnc. I think you are right... :) > ? ?if (_verbose_flag || level != MSG_INFO) { > ? ? ? ?if (level != MSG_INFO) { > ? ? ? ? ? ?if (prefix_str != NULL) { > ? ? ? ? ? ? ? ?fprintf(stderr, "%s", prefix_str); > ? ? ? ? ? ?} > ? ? ? ? ? ?va_start(ap, fmt); > ? ? ? ? ? ?vfprintf(stderr, fmt, ap); > ? ? ? ? ? ?va_end(ap); > ? ? ? ?} > ? ? ? ?if (prefix_str != NULL) { > ? ? ? ? ? ?fprintf(stdout, "%s", prefix_str); > ? ? ? ?} > ? ? ? ?va_start(ap, fmt); > ? ? ? ?vfprintf(stdout, fmt, ap); > ? ? ? ?va_end(ap); > ? ?} Seems the most sensible thing to me, I have included this in CVS for the next MINC release (2.1 due soon). Thanks again, -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From jcupitt at gmail.com Tue Jul 27 03:44:02 2010 From: jcupitt at gmail.com (jcupitt at gmail.com) Date: Tue, 27 Jul 2010 08:44:02 +0100 Subject: [MINC-development] bug in upet2mnc In-Reply-To: References: Message-ID: On 27 July 2010 07:40, Andrew Janke wrote: > On Fri, Jul 23, 2010 at 21:25, ? wrote: >> Hi, I think I've found a bug in upet2mnc. > > Seems the most sensible thing to me, I have included this in CVS for > the next MINC release (2.1 due soon). I forgot to say, I searched the minc-tools source for similar problems, but couldn't find the same scrap of code anywhere else. So it's probably an isolated bug. John From jason at phenogenomics.ca Wed Jul 28 12:17:17 2010 From: jason at phenogenomics.ca (Jason Lerch) Date: Wed, 28 Jul 2010 12:17:17 -0400 Subject: [MINC-development] minc2 bug Message-ID: <4C50580D.9000803@phenogenomics.ca> Greetings all, found a minc2 API bug, I think. The symptoms: miget_real_value and miget_real_value_hyperslab don't return the same value (which they should) if the underlying data is float or double (and there's some slice scaling? Not sure about the last part). The likely cause: miget_real_value blindly does voxel to real conversion regardless of the underlying data type (float and double don't need this conversion, if my minc foo is up to date). Here's a bit of code to test this: ==== #include #include int main(int argc, char **argv) { unsigned long location[3]; unsigned long count[3]; double test_voxel, test_hyper, test_voxel_value; int result; mihandle_t hvol; mitype_t data_type; location[0] = 50; location[1] = 50; location[2] = 50; count[0] = 1; count[1] = 1; count[2] = 1; result = miopen_volume(argv[1], MI2_OPEN_READ, &hvol); if (result != MI_NOERROR) { fprintf(stderr, "Error opening file %s \n", argv[1]); exit(1); } result = miget_real_value_hyperslab(hvol, MI_TYPE_DOUBLE, location, count, &test_hyper); if (result != MI_NOERROR) { fprintf(stderr, "Error getting voxel from hyperslab\n"); exit(1); } result = miget_real_value(hvol, location, 3, &test_voxel); if (result != MI_NOERROR) { fprintf(stderr, "Error getting voxel using miget_real_value\n"); exit(1); } result = miget_voxel_value(hvol, location, 3, &test_voxel_value); if (result != MI_NOERROR) { fprintf(stderr, "Error getting voxel using miget_voxel_value\n"); exit(1); } result = miget_data_type(hvol, &data_type); if (result != MI_NOERROR) { fprintf(stderr, "Error getting data type\n"); exit(1); } if (data_type == MI_TYPE_FLOAT || data_type == MI_TYPE_DOUBLE) { printf("Float or double found - trouble ahead?\n"); } else { printf("Something other than float - clear sailing?\n"); } printf("get_voxel value: %f\nget_hyperslab value: %f\nRaw Voxel value %f:\n", test_voxel, test_hyper, test_voxel_value); return(0); } === And here's a potential fix: in libsrc2/convert.c, replace: int miget_real_value(mihandle_t volume, const unsigned long coords[], int ndims, double *value_ptr) { double voxel; int result; result = miget_voxel_value(volume, coords, ndims, &voxel); if (result != MI_NOERROR) { return (result); } miconvert_voxel_to_real(volume, coords, ndims, voxel, value_ptr); return (MI_NOERROR); } with this: int miget_real_value(mihandle_t volume, const unsigned long coords[], int ndims, double *value_ptr) { double voxel; int result; mitype_t data_type; result = miget_voxel_value(volume, coords, ndims, &voxel); if (result != MI_NOERROR) { return (result); } result = miget_data_type(volume, &data_type); if (result != MI_NOERROR) { return (result); } if (data_type == MI_TYPE_FLOAT || data_type == MI_TYPE_DOUBLE) { *value_ptr = voxel; } else { miconvert_voxel_to_real(volume, coords, ndims, voxel, value_ptr); } return (MI_NOERROR); } Somebody with more minc2 knowledge should check this - it's also possible that the fix should be in miconvert_voxel_to_real instead. Jason From nikelski at bic.mni.mcgill.ca Wed Jul 28 15:13:28 2010 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Wed, 28 Jul 2010 12:13:28 -0700 Subject: [MINC-development] MINC, RMINC and -fPIC In-Reply-To: References: <20100724170812.GC3633@sumost.ca> Message-ID: Hi all, >So perhaps then it is best to leave things are they are and just use >--enable-shared --with-pic when making binaries? Yup, I tested this and all was OK. Andrew, if you would like to make a version of the 2.1 minc pre-release package available to me (Ubuntu Lucid), I would be happy to test it against RMINC on 32 and 64 bit. Although I always build my own tools, I would really like the new RMINC to work for the "normal" user who uses the pre-builts. Cheers, -jim -- ================================= 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