[Freesurfer] Building from source #3 -- dynamic binding

[Yaroslav Halchenko]

Dear FreeSurfer developers,

I would like to pick up on this elderly theme by wondering:

Would you be philosophically opposed against patches/pull requests
which introduce dynamic linking for freesurfer build?  

Would anyone from the FreeSurfer team be interested to pursue such
an effort?

The idea is to try to reincarnate the effort of pulling
functionality/binary-code which is now spread/duplicated across many
distributed statically linked binaries, into a set of (internal)
libraries.  Benefits IMHO are numerous, starting from

- smaller binary distribution

- consistency (replacing one patched binary copy but leaving the
  other copies which linked statically unpatched)

- ...


Cheers,

On Sun, 21 Feb 2016, Yaroslav Halchenko wrote:
> On Sun, 21 Feb 2016, zkauf...@nmr.mgh.harvard.edu wrote:

> > This topic gets brought up occasionally and their are valid arguments
> > to both sides. One reason we have hesitated to use dynamic libs is the
> > partly due to freesurfers long release cycle (all subjects that are
> > part of a study need to be performed all on the same version). This
> > long release cycle sometimes necessitates fixes to a particular binary
> > in the stream, which users are then free to use. Although this is a
> > less than ideal release strategy, it is the reality of the situation.
> > And if we linked against dynamic libs than any time a binary was
> > updated, ALL those libs, would need to be updated,
> > which in turn would affect all binaries which link against them. 

> AFAIK it is exactly the other way around ;) Please correct me if I
> am wrong.

> With static inclusion of code, if the fix is in the code which is shared
> among binaries, you will need  to provide new copies for all those
> effected binaries so they come with new copies of that code.   Only if
> the fix is within code specific to the binary -- only that binary
> indeed.

> In case if that 'fixed' code being a part of an internal dynamic library
> [*], you would need to provide only a copy of that library, and binaries
> linked against it can stay original since they just dynamically load
> that code from the library and do not carry broken code.   If it
> is a fix to the code specific to the binary -- situation is just the
> same as with static linking.

> [*] under assumption that the fix doesn't entail changing  API/ABI.  In
> case if those change -- indeed adjustment/rebuild of dependent binaries
> would be necessary.  BUT such situations come much less often than just
> fixes of the code without changing data structures and function
> interfaces. And in your case, even if that happens, it is just a matter
> again of uploading all those affected binaries (as you would do with
> static linking) + the dynamic library.  And again, I think, even if a
> binary uses some functionality of the library, but not a 'fixed'
> function, it could as well stay without 'update' while linking to
> the new dyn library.

> That is the primary reason why Linux distributions rely on dynamic
> libraries and reusing system-wide installed artifacts (e.g. java script
> "libraries", Python modules, etc) as often as possible -- to fix a
> vulnerability in the code of a core library/artifact requires just
> upload of the fixed library/artifact without rebuilding all binaries (or
> replacing all copies of artifacts) which could have potentially absorbed
> that code via static "linking".  Could you imagine the chaos if
> libc was statically included in every binary and then security fix
> was needed to propagate to all 30,000 packages? ;)


> > I suppose only newly released binaries could be static,
> > but their may be unintended consequences that Im not thinking of at the
> > moment.

> > Im open to conversing about this, and appreciate any constructive feedback
> > on improving our release model. 

> Well -- I can't recommend anything new really, and just repeat my
> whining: modularize just a bit (e.g. separate package for heavy data
> pieces which rarely change + dynamic libraries, you already have that
> bundle of externals you could deploy and reuse), and then you can
> easily release not just "binary patches" but entire bugfix releases of
> the codebase since they will probably be a fraction of the current size.
> That is AFAIK how anything is released these days really ;)

> NB. somewhat crazier scheme could be -- release binaries via git-annex,
> with upgrades constituting "git pull; git annex get . " ;) It
> would become especially efficient in case of dynamic internal
> libraries, since fetching a bugfix release would be to fetch only
> affected dynamic libraries and not all affected binaries linking against
> them.

> > But I would prefer to take the
>

Re: [Freesurfer] Building from source #2 -- dynamic binding

[Yaroslav Halchenko]

On Sun, 21 Feb 2016, R Edgar wrote:

> On 21 February 2016 at 22:33,   wrote:
> > Intolerable differences have not been found. They are always minor <%5 and
> > their source can come from several places. For example, different
> > compilers (or even different versions of the same compiler) can have
> > different sorting behavior when presented with objects that have
> > equivalent comparators. Others occur with data structures being
> > written/read to disk (Im still trying to fully understand those). As well
> > as a host of other potential differences as you mention below.

> > However, no cases have been found to fall outside expected and accepted
> > tolerance levels.

> That's a relief, but it makes me wonder about another point (and
> please understand that I'm making the following statement from a
> position of ignorance as to how Freesurfer is used in practice):

> Shouldn't differences like this be embraced? They are giving a measure
> of the error bars which should be applied to any results.

> I'd be interested in hearing people's thoughts about this.

> Going back to smaller and concrete things, I'm also curious as to the
> differences you say are creeping in when IO occurs. Is this happening
> for formatted or binary I/O?

Before commenting I want to state that this sub-thread is IMHO
off-topic, since I don't think it shouldn't (theoretically) have
to do anything with dynamic linking of internal code ...

IO issues also Z K mentioned also sounded interesting to my ear ;)
smells like alignment issues or uninitialized memory somewhere --
valgrind could be of great help here...  eventually, whenever a proper
debian package of freesurfer would see a daylight and there would be
some unit-tests, building/testing on exotic platforms such as
big-endians (powerpc, sparc, s390x) and the ones with stricter alignment
requirements (iirc armhf) can help to pin down locations of such bugs
since then e.g. 0x1 becomes 0x1 and thus sticking into your face ;)
(we have encounter such ones from time to time with e.g. numpy and
scipy)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Building from source #2 -- dynamic binding

[Yaroslav Halchenko]

On Sun, 21 Feb 2016, zkauf...@nmr.mgh.harvard.edu wrote:

> This topic gets brought up occasionally and their are valid arguments
> to both sides. One reason we have hesitated to use dynamic libs is the
> partly due to freesurfers long release cycle (all subjects that are
> part of a study need to be performed all on the same version). This
> long release cycle sometimes necessitates fixes to a particular binary
> in the stream, which users are then free to use. Although this is a
> less than ideal release strategy, it is the reality of the situation.
> And if we linked against dynamic libs than any time a binary was
> updated, ALL those libs, would need to be updated,
> which in turn would affect all binaries which link against them. 

AFAIK it is exactly the other way around ;) Please correct me if I
am wrong.

With static inclusion of code, if the fix is in the code which is shared
among binaries, you will need  to provide new copies for all those
effected binaries so they come with new copies of that code.   Only if
the fix is within code specific to the binary -- only that binary
indeed.

In case if that 'fixed' code being a part of an internal dynamic library
[*], you would need to provide only a copy of that library, and binaries
linked against it can stay original since they just dynamically load
that code from the library and do not carry broken code.   If it
is a fix to the code specific to the binary -- situation is just the
same as with static linking.

[*] under assumption that the fix doesn't entail changing  API/ABI.  In
case if those change -- indeed adjustment/rebuild of dependent binaries
would be necessary.  BUT such situations come much less often than just
fixes of the code without changing data structures and function
interfaces. And in your case, even if that happens, it is just a matter
again of uploading all those affected binaries (as you would do with
static linking) + the dynamic library.  And again, I think, even if a
binary uses some functionality of the library, but not a 'fixed'
function, it could as well stay without 'update' while linking to
the new dyn library.

That is the primary reason why Linux distributions rely on dynamic
libraries and reusing system-wide installed artifacts (e.g. java script
"libraries", Python modules, etc) as often as possible -- to fix a
vulnerability in the code of a core library/artifact requires just
upload of the fixed library/artifact without rebuilding all binaries (or
replacing all copies of artifacts) which could have potentially absorbed
that code via static "linking".  Could you imagine the chaos if
libc was statically included in every binary and then security fix
was needed to propagate to all 30,000 packages? ;)


> I suppose only newly released binaries could be static,
> but their may be unintended consequences that Im not thinking of at the
> moment.

> Im open to conversing about this, and appreciate any constructive feedback
> on improving our release model. 

Well -- I can't recommend anything new really, and just repeat my
whining: modularize just a bit (e.g. separate package for heavy data
pieces which rarely change + dynamic libraries, you already have that
bundle of externals you could deploy and reuse), and then you can
easily release not just "binary patches" but entire bugfix releases of
the codebase since they will probably be a fraction of the current size.
That is AFAIK how anything is released these days really ;)

NB. somewhat crazier scheme could be -- release binaries via git-annex,
with upgrades constituting "git pull; git annex get . " ;) It
would become especially efficient in case of dynamic internal
libraries, since fetching a bugfix release would be to fetch only
affected dynamic libraries and not all affected binaries linking against
them.

> But I would prefer to take the
> conversation offline as it gets overly technical rather quick.

ah (I was replying inline without reading all the way till the
end, sorry ;)), then this will be the last one then on this mailing list
in this series.  Could there may be a freesurfer-devel mailing list to
discuss such topics? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose 

[Freesurfer] Building from source -- [wishlist] please version the -packages.tar.gz

[Yaroslav Halchenko]

ATM
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/fs_supportlibs/prebuilt/centos6_x86_64/centos6-x86_64-packages.tar.gz
has no versioned counterpart.  Could you please provide some versioning
e.g. by actually having

centos6-x86_64-packages-0.0.20151104.tar.gz  (based on its modification
date, 0.0. to signal that it is not much of a real version), or
following any other versioning scheme (e.g. base on version of
freesurfer they were produced for)

with 

centos6-x86_64-packages.tar.gz symlink pointing to it, so webserver (if
FollowSymlinks) still resolving to that tarball

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Building from source #2 -- dynamic binding

[Yaroslav Halchenko]

On Sat, 20 Feb 2016, Bruce Fischl wrote:

> hmmm, the only thing that worries me about dynamic linking is that it 
> will add variability to the outputs. Zeke has spent endless amounts of time 
> tracking down e.g. mac vs. pc differences in math libs and such. Won't 
> dynamic linking just make that a much more prevalent problem?

nope -- I am not talking about dynamically linking external libraries
ATM, but first about the internal ones, where the common code where
instead of absorbing the same .a or .o blobs into multiple binaries,
there would be a set of internal dynamic libraries which those
binaries would be linked against, so there will no copies of
binary code among different binaries.  I guess
https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html
is a quick intro into those.

As for linking against external libraries -- those could be bundled
along with rpath pointing to their location or LD_LIBRARY_PATH
override assuring they are picked up (instead of possibly available
identically named system-wide ones). 

So overall it is possible to achieve absent variability while using
dynamic linking and allowing for possibility of the flexibility ;)

Cheers
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Building from source #2 -- dynamic binding

[Yaroslav Halchenko]

Hi again,

While our "building from source" discussion is "hot" I wondered to ask
if there was an attempt or may be plans for to switch to using dynamic
linking (and collect functionality within a few internal
libraries) instead of static duplication of binary code across
binaries.

At some point Michael Hanke and me have tried to achieve such a goal:
http://anonscm.debian.org/cgit/pkg-exppsy/freesurfer.git/tree/debian/patches/internal_shared_libs
(although a bit also mixing up with linking against system wide
libraries) so overall it is possible and should shrink currently sized
at almost 4GB bin (stripped of debug symbols) into probably (forgot the
size we got then) 50-100MB.  I expect similar or may be even more
drastic effect on debug symbols files (which are useful to provide as an
option).  I hope I don't need to outline why 10-fold cut down in
binaries size would be a good thing ;)

So I wondered, if there are any plans, and if not (yet) -- may be we
could proceed together to achieve that goal?  above experiment with
creating and maintaining that huge patch ourselves obviously has failed,
but taking incremental steps we might succeed eventually, IFF such
changes would be accepted upstream (i.e. into your code).  Or do
you see any possible reason why assembling few of internal dynamic
libraries and linking against your libraries bundle would be a no go?

With best regards,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Building from source -- autoconf error

[Yaroslav Halchenko]

On Fri, 19 Feb 2016, Z K wrote:

> Hello Yaroslav,

> Ive built freesurfer on Debian "Jessie" platform. It was just a matter 
> of adding "libtool-bin" and "tcsh" to the list of packages that need to 
> be installed. 

I had tcsh but not libtool-bin installed in that chroot... heh

> Ive update the wiki page:
> https://surfer.nmr.mgh.harvard.edu/fswiki/freesurfer_linux_developers_page

> I still wasnt quite able to get the freeview GUI to build. But If you 
> change the "--disable-GUI-build" flag to "--without-qt" then you will 
> get all the tktool GUIs except freeview. Im working on getting freeview 
> to build at the moment and will update the wiki page once I figure it out.

sweet! thanks.  I will give it a shot!

in my case I have got stuck still on 14.04 trying to build with GUI but
./configure failed to find xawplus rightfully so since even
centos6-x86_64-packages provides only a static build of it while
configure sensing for a dynamic library.  (and debian/ubuntus do
not provide this antiquity) 

I just wondered how do you guys build against it then? ;) 

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Building from source -- autoconf error

[Yaroslav Halchenko]

On Thu, 18 Feb 2016, Z K wrote:
> > is there a public clone of freesurfer on github?

> Sorry, their is no public freesurfer on github. But at the current 
> moment (and forseeable future) the public repo is an exact mirro of the 
> private repo.


> > --disable-GUI-build  -- wouldn't it disable then building all so necessary 
> > GUI
> > tools?  is there  a way to overcome the shortcoming?


> I was never able to get the GUI tools to build on Ubuntu. It is 
> something I may revisit in the near future, but as of now, in order to 
> build on an Ubuntu platform you will need to disable GUI building.

just confirming that I have managed to build it under 14.04 -- hip hip
hoorray! ;)  next one will be to try with GUI ;)

the only concern is that currently some subdirs makefiles do not care about
DESTDIR, which is generally respected by autotools... attached patch should
help (if only there was a public github... ;)) to make it 'installable' e.g. via

make install DESTDIR=$PWD/INSTALL-DIR/

it would be a nice "test" to add to .travis.yml upon successful build, without
system wide installation with sudo ;)

> We simply dont have the resources to ensure build capability on all 
> linux (and mac) based OSes. For now simply we make the claim that 
> freesurfer will build on centos, and will run on nearly all the major 
> linux distros.

Fair enough.  but may be together we could push it forward step by step
;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
From 1983364a101d9543f6d80c45b968aa194e023288 Mon Sep 17 00:00:00 2001
From: Yaroslav Halchenko <deb...@onerussian.com>
Date: Fri, 19 Feb 2016 05:06:24 +
Subject: [PATCH] BF: adjusted use of $(DESTDIR) so installs fine under DESTDIR

---
 BrainstemSS/Makefile.am | 4 ++--
 BrainstemSS/linux_x86_64/Makefile.am| 4 ++--
 GEMS/data/Makefile.am   | 4 ++--
 HippoSF/Makefile.am | 4 ++--
 HippoSF/linux_x86_64/Makefile.am| 4 ++--
 distribution/average/Buckner_JNeurophysiol11_MNI152/Makefile.am | 4 ++--
 distribution/average/Choi_JNeurophysiol12_MNI152/Makefile.am| 4 ++--
 distribution/average/Makefile.am| 4 ++--
 distribution/average/Yeo_JNeurophysiol11_MNI152/Makefile.am | 4 ++--
 distribution/average/surf/Makefile.am   | 4 ++--
 distribution/fsafd/Makefile.am  | 4 ++--
 distribution/fsl-extra/Makefile.am  | 2 +-
 distribution/lib/bem/Makefile.am| 4 ++--
 distribution/subjects/Makefile.am   | 4 ++--
 fsfast/docs/Makefile.am | 4 ++--
 images/Makefile.am  | 4 ++--
 matlab/Makefile.am  | 8 
 mri_cvs_register/Makefile.am| 2 +-
 qdec/Makefile.am| 8 
 talairach_avi/Makefile.am   | 4 ++--
 20 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/BrainstemSS/Makefile.am b/BrainstemSS/Makefile.am
index d0d505e..3bcf40e 100644
--- a/BrainstemSS/Makefile.am
+++ b/BrainstemSS/Makefile.am
@@ -21,8 +21,8 @@ segmentBS.sh \
 quantifyBrainstemStructures.sh
 
 install-data-local:
-	test -z $(foodir) || $(mkdir_p) $(foodir)
-	$(INSTALL_DATA) $(foo_datafiles) $(foodir)
+	test -z $(DESTDIR)$(foodir) || $(mkdir_p) $(DESTDIR)$(foodir)
+	$(INSTALL_DATA) $(foo_datafiles) $(DESTDIR)$(foodir)
 
 # Our release target. Include files to be excluded here. They will be
 # found and removed after 'make install' is run during the 'make
diff --git a/BrainstemSS/linux_x86_64/Makefile.am b/BrainstemSS/linux_x86_64/Makefile.am
index 3543581..0f47fd7 100644
--- a/BrainstemSS/linux_x86_64/Makefile.am
+++ b/BrainstemSS/linux_x86_64/Makefile.am
@@ -17,8 +17,8 @@ foo_binaryfiles = \
 	SegmentSubject.bin
 
 install-data-local:
-	test -z $(foodir) || $(mkdir_p) $(foodir)
-	$(INSTALL) -m 755 $(foo_binaryfiles) $(foodir)
+	test -z $(DESTDIR)$(foodir) || $(mkdir_p) $(DESTDIR)$(foodir)
+	$(INSTALL) -m 755 $(foo_binaryfiles) $(DESTDIR)$(foodir)
 
 # Our release target. Include files to be excluded here. They will be
 # found and removed after 'make install' is run during the 'make
diff --git a/GEMS/data/Makefile.am b/GEMS/data/Makefile.am
index 97a7eb1..cf29198 100644
--- a/GEMS/data/Makefile.am
+++ b/GEMS/data/Makefile.am
@@ -15,8 +15,8 @@ kvlQuantifyHippocampalSubfieldSegmentation

Re: [Freesurfer] Building from source -- autoconf error

[Yaroslav Halchenko]

On Thu, 18 Feb 2016, Z K wrote:

> I beleive the .travis.yml does work but it is still under active
> development.

is there a public clone of freesurfer on github?

> The Ubuntu instructions in the linux developers page have been tested on a
> clean install and should work
> (https://surfer.nmr.mgh.harvard.edu/fswiki/freesurfer_linux_developers_page).

oh good good -- thanks.. immediate question for 14.04 ubuntu then

--disable-GUI-build  -- wouldn't it disable then building all so necessary GUI
tools?  is there  a way to overcome the shortcoming?

> However I have not yet tested a build on a Debian system. I will make an
> attempt to build today on a clean debian "jessie" install. 

I would be infinitely grateful if freesurfer could build natively on Debian
stable! ;)  Thanks for trying.  In my case I am trying the build under jessie
chroot (using schroot helper), so I could quickly setup/enter such environment
while maintaining user/directory.  I will do the same now for 14.04.  If you
would like more -- let me know I could give a bit more detailed
instructions.

> But I have one
> question, what branch are you attempting to build, because their is no
> "stable5_branch-5622-gf3d0bcd" branch in the git repo?

;) it is an output of 'git describe --tags', which bases it on a most
recent tag, which was 5622 commits ago and its hexsha f2d0bcd.  You
could feed this beast to git directly -- it would swallow:

$> git show stable5_branch-5622-gf3d0bcd | head
commit f3d0bcd7c4ee8604918725de07c8736191cb1b8f
Author: Z K 
Date:   Tue Feb 16 17:03:00 2016 -0500

Changed to reference new GCA. -greve

diff --git a/scripts/recon-all b/scripts/recon-all
index 6e4ab62..bf35521 100755
--- a/scripts/recon-all
+++ b/scripts/recon-all


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Building from source -- autoconf error

[Yaroslav Halchenko]

Hi Z K et al,

What would be the recommended/tested debian/ubuntu release to approach the
build with some guarantee of success?  Is the .travis.yml "exercised" (failed
to quickly find a sign of it on travis-ci.org)?

I have tried on debian jessie to build stable5_branch-5622-gf3d0bcd of
the git/annex repo, using following command:

{ ./setup_configure && ./configure --prefix=/usr/local/freesurfer/dev 
--with-pkgs-dir=${PWD}/../freesurfer-packages/centos6-x86_64-packages 
--disable-Werror --with-petsc-dir=/usr/lib/x86_64-linux-gnu && make -j3; } 2>&1 
| tee ../freesurfer-upstream.buildlog1.txt

and before that installing various build depends and helpers through

apt-get install libtool automake gfortran libglu1-mesa-dev libfreetype6-dev 
uuid-dev libxmu-dev libxmu-headers libxi-dev libx11-dev libxt-dev libxaw7-dev 
liblapack-dev tcsh curl git libmpich-dev git git-annex petsc-dev make

but the build fails with

mv -f .deps/xmlToHtml.Tpo .deps/xmlToHtml.Po
/bin/bash ../libtool  --tag=CC   --mode=link g++-L/usr/lib64 
-L/usr/X11R6/lib64  -fopenmp
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/mni/current/lib
 
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/vxl/current/lib
  
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/itk/current/lib/InsightToolkit
  -o xmlToHtml xmlToHtml.o ../xml2/libxml2.a -lz 
mv -f .deps/fsPrintHelp-fsPrintHelp.Tpo .deps/fsPrintHelp-fsPrintHelp.Po
../libtool: line 469: CDPATH: command not found
/bin/bash ../libtool  --tag=CC   --mode=link g++ -DBUILD_MAIN   -L/usr/lib64 
-L/usr/X11R6/lib64  -fopenmp
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/mni/current/lib
 
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/vxl/current/lib
  
-L/home/yoh/deb/gits/pkg-exppsy/freesurfer-upstream/../freesurfer-packages/centos6-x86_64-packages/itk/current/lib/InsightToolkit
  -o fsPrintHelp fsPrintHelp-fsPrintHelp.o ../xml2/libxml2.a -lz 
../libtool: line 469: CDPATH: command not found
libtool: Version mismatch error.  This is libtool 2.4.2 Debian-2.4.2-1.11, but 
the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 
Debian-2.4.2-1.11
libtool: and run autoconf again.
Makefile:1674: recipe for target 'xmlToHtml' failed
make[3]: *** [xmlToHtml] Error 63
make[3]: *** Waiting for unfinished jobs
libtool: Version mismatch error.  This is libtool 2.4.2 Debian-2.4.2-1.11, but 
the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 
Debian-2.4.2-1.11
libtool: and run autoconf again.
Makefile:1658: recipe for target 'fsPrintHelp' failed
make[3]: *** [fsPrintHelp] Error 63

suggesting that not full auto/libtool'ification was carried out by
./setup_configure, but I didn't check detail yet.

full log available at 
http://www.onerussian.com/tmp/freesurfer-upstream.buildlog1.txt

Thanks in advance for the hints

On Tue, 02 Feb 2016, Z K wrote:

> Hello Alle,

> The naming of "configure.in" vs. "configure.ac" is not the issue. The 
> script is erroring out because file 'm4/autotroll.m4' does not exist. Do 
> you have that file (it should have been included in the checkout)?

> I would recommend using our git repo which mirrors our CVS repo. Please 
> see the following page:


> https://surfer.nmr.mgh.harvard.edu/fswiki/freesurfer_linux_developers_page

> Hope this helps,

> -Zeke

> On 02/02/2016 04:11 AM, Alle Meije Wink wrote:
> > I'm trying to build FreeSurfer from source on my Debian 8 (jessie) system.
> > (64 bit, using g++ 4.9 for compilation)

> > After
> > $ cvs -d :pserver:anonym...@fsvm.nmr.mgh.harvard.edu:/usr/fscvsroot login
> > $ cvs -d :pserver:anonym...@fsvm.nmr.mgh.harvard.edu:/usr/fscvsroot
> > checkout -P dev
> > $ cd dev
> > $ cvs update -d # just to make sure
> > $ ./setup_configure

> > I get these messages:

> > rm -rf autom4te.cache
> > libtoolize --force
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
> > libtoolize: linking file `config/ltmain.sh'
> > libtoolize: putting macros in `m4'.
> > libtoolize: linking file `m4/libtool.m4'
> > libtoolize: linking file `m4/ltoptions.m4'
> > libtoolize: linking file `m4/ltsugar.m4'
> > libtoolize: linking file `m4/ltversion.m4'
> > libtoolize: linking file `m4/lt~obsolete.m4'
> > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
> > libtoolize: rerunning libtoolize, to keep the correct libtool macros 
> > in-tree.
> > aclocal
> > aclocal: warning: autoconf input should be named 'configure.ac', not
> > 'configure.in'
> > aclocal: error: configure.in:2045: file 'm4/autotroll.m4' does not exist

> > Which looks like a not-(anymore)supported use of autoconf?
> 

Re: [Freesurfer] Error compiling freesurfer

[Yaroslav Halchenko]

lacking -lXmu
?

On Wed, 25 May 2011, Jordi Delgado wrote:
../hipsstubs/libhipsstubs.a ../log/liblog.a ../xml2/libxml2.a
../jpeg/libjpeg.a ../tiff/libtiff.a ../expat/libexpat.a -lGLU -lGL
-L/usr/X11R6/lib -lX11  -lm  ../glut/libglut.a -lz -lm -lcrypt -ldl
-lpthread -lnetcdf -lvolume_io -lminc -lvnl_algo -lvnl -lvcl
-lnetlib -lv3p_netlib
libtool: link: warning: library
`/tmp/packages/mni/current/lib/[1]libvolume_io.la' was moved.
libtool: link: warning: library
`/tmp/packages/mni/current/lib/[2]libminc.la' was moved.
libtool: link: warning: library
`/tmp/packages/mni/current/lib/[3]libvolume_io.la' was moved.
libtool: link: warning: library
`/tmp/packages/mni/current/lib/[4]libminc.la' was moved.
g++ -o mris_show mris_show.o  -L/tmp/packages/mni/current/lib
-L/tmp/packages/vxl/current/lib -L/usr/X11R6/lib ../utils/libutils.a
../rgb/librgb.a ../unix/libunix.a ../dicom/libdicom.a
../hipsstubs/libhipsstubs.a ../log/liblog.a ../xml2/libxml2.a
../jpeg/libjpeg.a ../tiff/libtiff.a ../expat/libexpat.a -lGLU
/usr/lib/libGL.so -lXext -lX11 ../glut/libglut.a -lz -lcrypt -ldl
-lpthread /tmp/packages/mni/current/lib/libvolume_io.a
-L/usr/pubsw/packages/mni/current/lib
/tmp/packages/mni/current/lib/libminc.a -lnetcdf -lm -lvnl_algo -lvnl
-lvcl -lnetlib -lv3p_netlib
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`../utils/libutils.a(pgmstubs.o)' is incompatible with i386 output
../glut/libglut.a(glut_cmap.o): In function `__glutSetupColormap':
/tmp/dev/glut/glut_cmap.c:253: undefined reference to
`XmuLookupStandardColormap'
-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Neuroscience software survey: What is popular, what has problems? Immediate results

[Yaroslav Halchenko]

[Apologies for cross-posting]

Dear neuroscience researchers and IT staff

We invite you to participate in a survey on software usage and computing
environments in neuroscience research. It will take no more than five
minutes to fill it out. Immediately after sending your answers you will
get to see a summary of how other participants have responded before.
This data will eventually be made available to software vendors and
distributors to determine advantages and issue of popular computing
environments in neuroscience research.

Learn about what fellow neuroscientists are doing to address their computing
demands -- take the survey!

http://goo.gl/euIMc

Thanks,
-- 
PyMVPA/NeuroDebian Team:   Yaroslav O. Halchenko   Michael Hanke
Postdoctoral Fellows,  Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] CVS/Source distribution

[Yaroslav Halchenko]

Dear FreeSurfer Developers,

Thank you very much for providing source code exposed under CVS.

I wonder if there are any plans to either switch to another version
control system and/or provide source distribution in versioned
tarballs?

N.B.  I was asking about vcs change, because rich history of freesurfer
development since 1996 is not really accessible with CVS any longer (at
least to me with cvs 1:1.12.13-12 on Debian).  For instance if I
do

 cvs -d :pserver:anonym...@fsvm.nmr.mgh.harvard.edu:/usr/fscvsroot checkout -D 
 1996/02/26 dev

it fails with an error

...
U dev/utils/matfile.c
cvs [checkout aborted]: invalid change text in 
/usr/fscvsroot/dev/utils/matrix.c,v

are you observing similar behavior?

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Yaroslav Halchenko]

Hi Krish,

Thanks once again for providing that library. I came back to analyze the
data and got some problems storing the results into MGH format. Before I
try to figure out a fix (and send it back to you) I thought that may be
you could share an uptodated snapshot of the library (may be the issue I
am experiencing was already fixed).

Thank you in advance!

On Thu, 24 Apr 2008, Krish Subramaniam wrote:

 Hi Yaroslav and Pádraig,

 Please follow the link pasted below to get an alpha version of pymgh. It 
 requires the latest Python and Numpy.

 
 https://www.nmr.mgh.harvard.edu/facility/filedrop/showgroup/10224/1/2a5da2a125134fbdfc9e6850be1fcc09
  
  (expires in 30 days )

 Make sure PYTHONPATH has the directory which contains 'pymgh'. Found by 
 typing,
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] VNC/GLX... what is really vncserver.glx

[Yaroslav Halchenko]

Thanks! last time I looked at it there were no debian packages ready in
any shape... actually still that repository on wiki doesn't have any
recent freenx but 
http://tim.haegele.info/2008/03/28/nomachine-nx-libraries-and-freenx-server/
might be the way to go

Thanks once again!

NB free version of NX from nomachine wasn't stable enough for me -- I
was managing to crash it at least once in 2 days... VNC survives for up
to a month or so for me ;-)

On Fri, 25 Apr 2008, Paul Raines wrote:

 Another option to VNC is freenx.

 http://wiki.debian.org/freenx

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] thickness file data structure

[Yaroslav Halchenko]

well -- yeah... nifti is indeed has a 'short' limit on the size of a
dimension but I leave it open question 'what .mgh format has to do with
.nii' ;-)

Thank you guys very much for your rapid replies!

Cheers
Yarik

On Tue, 29 Apr 2008, Bruce Fischl wrote:

 I think it's because of nifti. Doug is out of town, but he's the one who  
 will be able to tell you definitively.

 cheers,
 Bruce
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Yaroslav Halchenko]

actually I need thickness data out of it. Is .mgh format documented
somewhere?

On Thu, 24 Apr 2008, Pádraig Kitterick wrote:

 How much detail do you need frmo the mgh file? I wrote a quick Python  
 script which reads in at least the volume data but I think I just passed  
 over most of the other stuff in there...

 Yaroslav Halchenko wrote:
 Does anyone know any handy module to at least read in .mgh files from
 Python? Or should I simply try mri_convert them into .minc and use
 netcdf module within python?

 Thanks in advance for the ideas!
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] VNC/GLX... what is really vncserver.glx

[Yaroslav Halchenko]

Thank you Tren,

Actually Nick Schmansky at the time of original request pointed me out
(I believe in an offlist conversation) to xf4vnc, I have built it
then from CVS snapshot (there were/are no source tarballs), but it was
segfaulting. Debian maintainer of VNC packages unfortunately isn't
really eager to jump into burden of building yet another VNC package for
Debian, so I just abandoned idea of using xf4vnc at that moment. May be
now is a good timing to give it a shout again ;)

On Thu, 24 Apr 2008, Tsung-Ren Huang wrote:

 Hi Yaroslav,

 You can comment out those lines regarding GLoverride.
 The real magic, as pointed out by Nick, is acutally the xf4vnc 
 that can be downloaded from http://sourceforge.net/projects/xf4vnc .

 Tren
d
  On Mon, 2007-01-15 at 23:27 -0500, Yaroslav Halchenko wrote:
  Thank you very much for providing the script.  Now the question is what
  magic do you keep under /usr/lib64/GLoverride:/usr/lib/GLoverride
  because the rest of the script seems to be close to the standard
  vnc server script shipped originally (Debian maintainer introduced some
  changes as well but most only for parameter/configuration
  specifications).

  On Tue, 16 Jan 2007, Nick Schmansky wrote:
  Yaroslav,
  If you goto that RemoteAccess wiki page, and click on 'vncserver.glx',
  it will now allow you to download that script.  You will have to modify
  it a bit: look for instances of /usr/pubsw/packages, which point to our
  installation of VNC.
  Nick


-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Yaroslav Halchenko]

Does anyone know any handy module to at least read in .mgh files from
Python? Or should I simply try mri_convert them into .minc and use
netcdf module within python?

Thanks in advance for the ideas!

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] VNC/GLX... what is really vncserver.glx

[Yaroslav Halchenko]

Thank you very much for providing the script.  Now the question is what
magic do you keep under /usr/lib64/GLoverride:/usr/lib/GLoverride
because the rest of the script seems to be close to the standard
vnc server script shipped originally (Debian maintainer introduced some
changes as well but most only for parameter/configuration
specifications).

On Tue, 16 Jan 2007, Nick Schmansky wrote:

 Yaroslav,

 If you goto that RemoteAccess wiki page, and click on 'vncserver.glx',
 it will now allow you to download that script.  You will have to modify
 it a bit: look for instances of /usr/pubsw/packages, which point to our
 installation of VNC.

 Nick
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] VNC/GLX... what is really vncserver.glx

[Yaroslav Halchenko]

Dear Freesurfer People,

From http://surfer.nmr.mgh.harvard.edu/fswiki/RemoteAccess we found out
that it seems MGH people have some custom script or a VNC server
(named vncserver.glx) which GLX support good enough to run freesurfer
within VNC session.

We have been using standard vnc4server which provides GLX
capabilities but unfortunately seems not all, so whenever we run
tksurfer (for instance) we get a lengthy list of following errors and
opengl canvas not painted at all

,---
| Received X error!
| Error code   : 158
| Request code : 148
| Minor code   : 2
|
| Error text : 'GLXBadLargeRequest'
`---

Could you please advice on what VNC server solution you are using for
freesurfer

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer