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

[Dicamillo, Robert]

Hello Yaroslav,

I believe there is already an option that can be set at configure time to build 
dynamical;ly, though
I have not tried it. e.g., maybe it causes the libraries that
Freesurfer builds internally to be built as shared instead of static.

However, at least in out nightly builds, the freesurfer binaries link
dynamically with the linux system libs.  It looks like there are about 130
linux system libraries referenced by all the ELF files in a built freesurfer 
tree.

By comparison I think there may be no more then 15 static libs built and linked
against inside the freesurfer tree.  While these could be built shared, I’m
not sure there is an expectation that end users should be able to replace/update
these libs within a release of Freesiurfer.

- rob


> On Mar 29, 2018, at 4:36 PM, Yaroslav Halchenko 
>  wrote:
> 
> 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 

[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
> > 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

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 

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

[R Edgar]

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?

Thanks,

Richard
___
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 -- [wishlist] please version the -packages.tar.gz

[zkaufman]

Yes this is a good idea. All subsequent 3rd party bundles will be
versioned as (or similar to) the way you describe below. Which is good
because a new one will be released soon. Thanks for the input.

-Zeke

> 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
>
>
>

___
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

[zkaufman]

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.

-Zeke




> On 20 February 2016 at 17:28, 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.
>
> What sort of differences were found? Differences in transcendental
> functions are to be expected (so long as they are small) and lots of
> other things can cause slightly different results to be generated from
> floating point calculations (for instance, when summing an array, the
> result might vary with the number of OpenMP threads used). Were the
> segmentations produced intolerably different?
>
> Regards,
>
> Richard
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>

___
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

[zkaufman]

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. 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. But I would prefer to take the
conversation offline as it gets overly technical rather quick.

-Zeke

>
> 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
>
>
>

___
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 -- [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

[R Edgar]

On 20 February 2016 at 17:28, 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.

What sort of differences were found? Differences in transcendental
functions are to be expected (so long as they are small) and lots of
other things can cause slightly different results to be generated from
floating point calculations (for instance, when summing an array, the
result might vary with the number of OpenMP threads used). Were the
segmentations produced intolerably different?

Regards,

Richard
___
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.

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

[Bruce Fischl]

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?
Bruce



On Sat, 20 Feb 2016, Yaroslav Halchenko 
wrote:

> 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,
>
___
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

[Z K]

Ive discovered that if you add the following line to the 
freeview/Makefile.am file then it will build succcessfully.

  freeview_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS)
  freeview_CPPFLAGS = $(QT_CPPFLAGS) $(AM_CPPFLAGS)
-freeview_LDFLAGS   = $(QT_LDFLAGS) $(OS_LDFLAGS)
+freeview_LDFLAGS   = $(QT_LDFLAGS) $(OS_LDFLAGS) \
+   -Wl,--allow-multiple-definition 
  freeview_LDADD= $(QT_LIBS)\
$(addprefix $(top_builddir)/, $(LIBS_MGH)) \
$(top_builddir)/vtkfsio/libvtkfsio.a \

Turns out the issue is with the build of LAPACK provided by Ubuntu, as 
it contains a duplicate function. (https://cmake.org/Bug/view.php?id=12912)

I will be committing the change and pushing to the git repo after some 
testing, probably later this evening.

-Zeke

On 02/19/2016 02:29 PM, Rudolph Pienaar wrote:
> I have been able to build the FS GUI tools succesfully on Ubuntu in the
> past... Admittedly this was a long time ago (pre 14.04 days). I can dig
> through my notes and see if they are still applicable. We no longer have
> any Ubuntu 14.04 boxes -- we're currently on 15.10 ... which I suppose
> in a few weeks will be superseded by 16.04's release.
>
>
> On 2/19/16 12:45 , 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. 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.
>>
>> -Zeke
>>
>>
>>
>>
>> On 02/18/2016 05:04 PM, Yaroslav Halchenko wrote:
>>> Gotcha, thanks!
>>>
>>> On February 18, 2016 3:27:21 PM EST, Z K  
>>> wrote:

> 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.
>

 I have a debian jessie system just setup, but I have a high priority
 project due Monday, so I would be able to begin determining the exact
 build procedure on Debian jessie until beginning of next week. It is
 something I have been meaning to do so I plan on getting to it. If you
 dont hear from me by Tuesday/Wedensday feel free to shoot me an email
 for an update. Thanks.

 -Zeke


 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 mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

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

[Rudolph Pienaar]

I have been able to build the FS GUI tools succesfully on Ubuntu in the 
past... Admittedly this was a long time ago (pre 14.04 days). I can dig 
through my notes and see if they are still applicable. We no longer have 
any Ubuntu 14.04 boxes -- we're currently on 15.10 ... which I suppose 
in a few weeks will be superseded by 16.04's release.


On 2/19/16 12:45 , 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. 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.
>
> -Zeke
>
>
>
>
> On 02/18/2016 05:04 PM, Yaroslav Halchenko wrote:
>> Gotcha, thanks!
>>
>> On February 18, 2016 3:27:21 PM EST, Z K  
>> wrote:
>>>
 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.

>>>
>>> I have a debian jessie system just setup, but I have a high priority
>>> project due Monday, so I would be able to begin determining the exact
>>> build procedure on Debian jessie until beginning of next week. It is
>>> something I have been meaning to do so I plan on getting to it. If you
>>> dont hear from me by Tuesday/Wedensday feel free to shoot me an email
>>> for an update. Thanks.
>>>
>>> -Zeke
>>>
>>>
>>> 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 mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>


-- 
Rudolph Pienaar, M.Eng, D.Eng / email: rudo...@nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street, Charlestown, MA 02129 USA
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

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

[Z K]

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. 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.

-Zeke




On 02/18/2016 05:04 PM, Yaroslav Halchenko wrote:
> Gotcha, thanks!
>
> On February 18, 2016 3:27:21 PM EST, Z K  wrote:
>>
>>> 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.
>>>
>>
>> I have a debian jessie system just setup, but I have a high priority
>> project due Monday, so I would be able to begin determining the exact
>> build procedure on Debian jessie until beginning of next week. It is
>> something I have been meaning to do so I plan on getting to it. If you
>> dont hear from me by Tuesday/Wedensday feel free to shoot me an email
>> for an update. Thanks.
>>
>> -Zeke
>>
>>
>> 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 mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

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 
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 @@ kvlQuantifyHippocampalSubfieldSegmentations.sh.help.xml \
 kvlSegmentHippocampalSubfields.sh.help.xml
 
 

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

[Z K]

>
> 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.

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.

>
> 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.
>

Working on it now. Ill be attempting the build under a vanilla jessie 
install.

>
> ;) 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
>

Got it! Thanks.

-Zeke
___
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:

> 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

[Z K]

Hello,

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

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). 


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. 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?

-Zeke

On 02/18/2016 09:59 AM, Yaroslav Halchenko wrote:
> 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 

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?
> 

[Freesurfer] Building from source -- autoconf error

[Alle Meije Wink]

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?
I found one previous message on the list about autotroll
  
https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2012-January/021854.html
that provided another version of configure.in which might solve the issue.

And it did in the original case but sadly not for me. I get the same
error message also with the new configure.in -- there should probably
be a configure.ac?

If anyone knows how to make this work (e.g. by modifying the configure
script) that would be fantastic.
___
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

[Z K]

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?
> I found one previous message on the list about autotroll
>
> https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2012-January/021854.html
> that provided another version of configure.in which might solve the issue.
>
> And it did in the original case but sadly not for me. I get the same
> error message also with the new configure.in -- there should probably
> be a configure.ac?
>
> If anyone knows how to make this work (e.g. by modifying the configure
> script) that would be fantastic.
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
___
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 without GUIs

[Nick Schmansky]

malcolm,

hi, i'm able to replicate that warning on that data, and i'm
investigating.  i would say its a false alarm, as that input data is
considered 'optimal' (mprage from our own scanners).

it appears the recon-all proceeded successfully all the way to nearly
the end.   it failed in some new code (you are working with our
'development' checkout, so new stuff often breaks the stream), so i'll
have to pass that failure along to that developer (thanks for catching
that!).

so i think your build seems fine.  i notice you are running on a
somewhat standard linux platform.  does the centos binary build that we
distribute not suit your needs?  just wanted to make sure you werent
under the impression that you have to build from scratch if you arent
running centos (people have made assumption in the past). the centos
build seems to run fine on nearly all x86 linux variants, sometimes with
some library tweeking.   its a help though to have developers such as
yourself build the source.

n.


On Wed, 2012-01-11 at 07:53 -0600, Malcolm Tobias wrote:
 Nick,
 
 I ran recon-all on bert and it did produce an error:
 
 recon-all -s ernie exited with ERRORS at Tue Jan 10 18:47:07 CST 2012
 
 A cursory glance at the recon-all.log showed:
 
 **
 *
 * WARNING: Registration did not converge in 5 steps! 
 *  Problem might be ill posed. 
 *  Please inspect output manually!
 *
 **
 
 I'm not sure if that's the real problem or whether it occurs further down in 
 the logs.  I've attached the entire log.
 
 Malcolm
 
 
 On Tuesday 10 January 2012 10:58:21 Nick Schmansky wrote:
  malcolm,
  
  running 'make check' is one way to check the build.  we run that nightly
  on our three build platforms (linux 32b, 64b and mac leopard).  a goal
  of our linux centos build is to have it run on as many linux variants as
  possible without people having to modify their local install, and to
  that end, we've found that some linux systems dont have libg2c
  installed, so what we do on our build platforms is to remove the
  libg2c.so (shared lib) file, leaving the .a (static lib), so that the
  shared lib dependency is removed.  you can either do the same (so far
  doing so hasnt broken other non-freesurfer apps), or you can skip it.
  
  you should run recon-all -all on 'bert', or any other data you have
  handy.  make sure it runs to completion without error.  checking the
  accuracy of the results against known prior runs is possible (we do this
  locally) but probably not necessary in your case, as your results might
  be different (due to platform differences) but not 'wrong'.  mainly you
  want to make sure recon-all doesnt hit some strange runtime problem
  (missing lib or whatnot).  remember you shouldn't mix results from your
  new platform with results from other platforms when conducting a group
  study (ie always do groups studies using results from the same platform
  and version).
  
  n
  
  On Tue, 2012-01-10 at 07:47 -0600, Malcolm Tobias wrote:
   Nick,
   
   Everything is now building successfully.  Thanks for your help!
   
   What do you normally do to test a build?  I tried running 'make check'
   which seemed pretty extensive.  While many tests passed:
   
   [root@login002 freesurfer-dev-20120106]# grep PASS make.check.out | wc -l
   407
   
   I did have one fail:
   
   ERROR: gauss_4dfp built against shared libg2c!
   FAIL: test_libg2c
   
   which seemed to stop the test process.  Is this something serious or can
   it be ignored?
   
   Malcolm
   
   On Monday 09 January 2012 15:43:34 Nick Schmansky wrote:
malcolm,

configure.in had another bug in it.  attached is a fix.  run
setup_configure again to regenerate configure.  its been awhile since
someone built a non-gui build offsite, so there could be other
problems.

n.

On Mon, 2012-01-09 at 15:07 -0600, Malcolm Tobias wrote:
 Nick,
 
 While configure now works, I'm getting a build-time error.
 
 It looks like:
 histo_register/SimpleBaseLib/include/sbl/image/Image.h
 
 has a dependency on OpenCV.  I didn't see OpenCV listed on the
 Developers Guide:
 
 https://surfer.nmr.mgh.harvard.edu/fswiki/DevelopersGuide
 
 Is this a new dependency?
 
 I tried using --without-opencv but that generated an error with
 freeview:
 
 make[2]: Entering directory
 `/export/src/freesurfer-dev-20120106/freeview' MainWindow.ui -p -o
 ui_MainWindow.h
 make[2]: MainWindow.ui: Command not found
 
 Any suggestions?
 
 Malcolm
 
 On Monday 09 January 2012 13:36:37 Nick Schmansky wrote:
  malcolm,
  
  can you try using the attached configure.in?  you will need to
  run ./setup_configure, which will create a new configure script.
  hopefully --disable-all-apps will then work.
  
  n.
  
 

Re: [Freesurfer] Building from source without GUIs

[Malcolm Tobias]

Nick,

On Wednesday 11 January 2012 11:52:19 Nick Schmansky wrote:
 it appears the recon-all proceeded successfully all the way to nearly
 the end.   it failed in some new code (you are working with our
 'development' checkout, so new stuff often breaks the stream), so i'll
 have to pass that failure along to that developer (thanks for catching
 that!).

Thanks for checking on this.  I have to rely on you guys for verification that 
the code is producing the correct results as I'm clueless about the science 
behind FreeSurfer.  I was pleasantly surprised at the extensive level of tests 
during make check.  More scientific applications should strive for this 
level of testing.

 so i think your build seems fine.  i notice you are running on a
 somewhat standard linux platform.  does the centos binary build that we
 distribute not suit your needs?  

The distributed binary works fine, but, we've got dozens of FreeSurfer users 
who sometimes submit hundreds of runs, so I'm hoping that any performance 
benefits we could squeeze out would have a big impact on our community.  On 
top of that, we have members of the Human Connectome Project using our cluster 
so it's possible that they'll need bleeding-edge versions of FreeSurfer in the 
future.

As an aside, the distributed binary ran for me in 11:41, where the custom 
built version ran in 10:44.  It's impossible to say whether this was due to 
building from scratch or a result of using the development branch.

My real goal is to revisit building with the Intel compilers (which I bugged 
you about 1 year ago).  I'm close, but that should be a topic for a different 
thread ;-)

Cheers,
Malcolm


-- 
Malcolm Tobias
314.362.1594

___
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 without GUIs

[Nick Schmansky]

malcolm,

running 'make check' is one way to check the build.  we run that nightly
on our three build platforms (linux 32b, 64b and mac leopard).  a goal
of our linux centos build is to have it run on as many linux variants as
possible without people having to modify their local install, and to
that end, we've found that some linux systems dont have libg2c
installed, so what we do on our build platforms is to remove the
libg2c.so (shared lib) file, leaving the .a (static lib), so that the
shared lib dependency is removed.  you can either do the same (so far
doing so hasnt broken other non-freesurfer apps), or you can skip it.

you should run recon-all -all on 'bert', or any other data you have
handy.  make sure it runs to completion without error.  checking the
accuracy of the results against known prior runs is possible (we do this
locally) but probably not necessary in your case, as your results might
be different (due to platform differences) but not 'wrong'.  mainly you
want to make sure recon-all doesnt hit some strange runtime problem
(missing lib or whatnot).  remember you shouldn't mix results from your
new platform with results from other platforms when conducting a group
study (ie always do groups studies using results from the same platform
and version).

n


On Tue, 2012-01-10 at 07:47 -0600, Malcolm Tobias wrote:
 Nick,
 
 Everything is now building successfully.  Thanks for your help!
 
 What do you normally do to test a build?  I tried running 'make check' which 
 seemed pretty extensive.  While many tests passed:
 
 [root@login002 freesurfer-dev-20120106]# grep PASS make.check.out | wc -l
 407
 
 I did have one fail:
 
 ERROR: gauss_4dfp built against shared libg2c!
 FAIL: test_libg2c
 
 which seemed to stop the test process.  Is this something serious or can it 
 be 
 ignored?  
 
 Malcolm
 
 On Monday 09 January 2012 15:43:34 Nick Schmansky wrote:
  malcolm,
  
  configure.in had another bug in it.  attached is a fix.  run
  setup_configure again to regenerate configure.  its been awhile since
  someone built a non-gui build offsite, so there could be other problems.
  
  n.
  
  On Mon, 2012-01-09 at 15:07 -0600, Malcolm Tobias wrote:
   Nick,
   
   While configure now works, I'm getting a build-time error.
   
   It looks like:
   histo_register/SimpleBaseLib/include/sbl/image/Image.h
   
   has a dependency on OpenCV.  I didn't see OpenCV listed on the Developers
   Guide:
   
   https://surfer.nmr.mgh.harvard.edu/fswiki/DevelopersGuide
   
   Is this a new dependency?
   
   I tried using --without-opencv but that generated an error with
   freeview:
   
   make[2]: Entering directory
   `/export/src/freesurfer-dev-20120106/freeview' MainWindow.ui -p -o
   ui_MainWindow.h
   make[2]: MainWindow.ui: Command not found
   
   Any suggestions?
   
   Malcolm
   
   On Monday 09 January 2012 13:36:37 Nick Schmansky wrote:
malcolm,

can you try using the attached configure.in?  you will need to
run ./setup_configure, which will create a new configure script.
hopefully --disable-all-apps will then work.

n.

On Mon, 2012-01-09 at 11:51 -0600, Malcolm Tobias wrote:
 Nick,
 
 I'm getting the same error:
 
 [root@login002 freesurfer-dev-20120106]# ./configure
 --disable-all-apps -- disable-gl-apps --disable-tcltk-apps
 -with-mni-dir=/export/minc-1.4/ --with- vxl-dir=/export/vxl-1.13.0
 ...
 configure: error: FATAL: libBLT not found. Check config.log. Set
 LDFLAGS or -- with-BLT-dir.
 
 I've attached the config.log.  Let me know if the mail-list software
 blocks it for any reason.
 
 Cheers,
 Malcolm
 
 On Monday 09 January 2012 11:09:03 Nick Schmansky wrote:
  try addong --disable-tcltk-apps  to your configure command line.
  
  --disable-all-apps appears to be broken.
  
  send me your config.log file if it still doesnt work.
  
  n.
  
  On Mon, 2012-01-09 at 09:51 -0600, Malcolm Tobias wrote:
   Nick,
   
   Tcl/Tk is installed on the system under /usr/bin so I can't
   exclude it from my path without breaking things.  VTK isn't in
   my path.
   
   Should the flags to disable the GUI stuff (--disable-all-apps
   --disable-gl- apps) be considered broken?  Any other suggestions
   for a work-around?  Would a copy of my configure output help?
   
   Malcolm
   
   On Saturday 07 January 2012 14:16:06 Nick Schmansky wrote:
the other way to build w/o gui support is to exclude the tcl
and vtk paths in configure.  in other works, only vtk and mni
should be included in your configure line.

On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
 I'm attempting to build the development branch of the source
 code. To reduce dependencies, I'm trying to build without any
 of the GUI support using the flags:
 
 

Re: [Freesurfer] Building from source without GUIs

[Malcolm Tobias]

Nick,

Tcl/Tk is installed on the system under /usr/bin so I can't exclude it from my 
path without breaking things.  VTK isn't in my path.

Should the flags to disable the GUI stuff (--disable-all-apps --disable-gl-
apps) be considered broken?  Any other suggestions for a work-around?  Would a 
copy of my configure output help?

Malcolm

On Saturday 07 January 2012 14:16:06 Nick Schmansky wrote:
 the other way to build w/o gui support is to exclude the tcl and vtk
 paths in configure.  in other works, only vtk and mni should be included
 in your configure line.
 
 On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
  I'm attempting to build the development branch of the source code.
  To reduce dependencies, I'm trying to build without any of the GUI
  support using the flags:
  
  --disable-all-apps
  --disable-gl-apps
  
  It's complaining about a missing dependency:
  
  configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS
  or -- with-BLT-dir.
  
  but the instructions imply that BLT is only necessary for GUIs.
  
  Are there additional arguments that I need to pass to configure?
  
  Malcolm
 
 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.


-- 
Malcolm Tobias
314.362.1594

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

Re: [Freesurfer] Building from source without GUIs

[Nick Schmansky]

try addong --disable-tcltk-apps  to your configure command line.

--disable-all-apps appears to be broken.

send me your config.log file if it still doesnt work.

n.


On Mon, 2012-01-09 at 09:51 -0600, Malcolm Tobias wrote:
 Nick,
 
 Tcl/Tk is installed on the system under /usr/bin so I can't exclude it from 
 my 
 path without breaking things.  VTK isn't in my path.
 
 Should the flags to disable the GUI stuff (--disable-all-apps --disable-gl-
 apps) be considered broken?  Any other suggestions for a work-around?  Would 
 a 
 copy of my configure output help?
 
 Malcolm
 
 On Saturday 07 January 2012 14:16:06 Nick Schmansky wrote:
  the other way to build w/o gui support is to exclude the tcl and vtk
  paths in configure.  in other works, only vtk and mni should be included
  in your configure line.
  
  On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
   I'm attempting to build the development branch of the source code.
   To reduce dependencies, I'm trying to build without any of the GUI
   support using the flags:
   
   --disable-all-apps
   --disable-gl-apps
   
   It's complaining about a missing dependency:
   
   configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS
   or -- with-BLT-dir.
   
   but the instructions imply that BLT is only necessary for GUIs.
   
   Are there additional arguments that I need to pass to configure?
   
   Malcolm
  
  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 mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Building from source without GUIs

[Malcolm Tobias]

Nick,

With the new configure.in, --disable-all-apps works as advertised.

Thanks!

Malcolm

On Monday 09 January 2012 13:36:37 Nick Schmansky wrote:
 malcolm,
 
 can you try using the attached configure.in?  you will need to
 run ./setup_configure, which will create a new configure script.
 hopefully --disable-all-apps will then work.
 
 n.
 
 On Mon, 2012-01-09 at 11:51 -0600, Malcolm Tobias wrote:
  Nick,
  
  I'm getting the same error:
  
  [root@login002 freesurfer-dev-20120106]# ./configure --disable-all-apps
  -- disable-gl-apps --disable-tcltk-apps -with-mni-dir=/export/minc-1.4/
  --with- vxl-dir=/export/vxl-1.13.0
  ...
  configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS
  or -- with-BLT-dir.
  
  I've attached the config.log.  Let me know if the mail-list software
  blocks it for any reason.
  
  Cheers,
  Malcolm
  
  On Monday 09 January 2012 11:09:03 Nick Schmansky wrote:
   try addong --disable-tcltk-apps  to your configure command line.
   
   --disable-all-apps appears to be broken.
   
   send me your config.log file if it still doesnt work.
   
   n.
   
   On Mon, 2012-01-09 at 09:51 -0600, Malcolm Tobias wrote:
Nick,

Tcl/Tk is installed on the system under /usr/bin so I can't exclude
it from my path without breaking things.  VTK isn't in my path.

Should the flags to disable the GUI stuff (--disable-all-apps
--disable-gl- apps) be considered broken?  Any other suggestions for
a work-around?  Would a copy of my configure output help?

Malcolm

On Saturday 07 January 2012 14:16:06 Nick Schmansky wrote:
 the other way to build w/o gui support is to exclude the tcl and
 vtk paths in configure.  in other works, only vtk and mni should
 be included in your configure line.
 
 On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
  I'm attempting to build the development branch of the source
  code. To reduce dependencies, I'm trying to build without any of
  the GUI support using the flags:
  
  --disable-all-apps
  --disable-gl-apps
  
  It's complaining about a missing dependency:
  
  configure: error: FATAL: libBLT not found. Check config.log. Set
  LDFLAGS or -- with-BLT-dir.
  
  but the instructions imply that BLT is only necessary for GUIs.
  
  Are there additional arguments that I need to pass to configure?
  
  Malcolm
 
 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 mailing list
   Freesurfer@nmr.mgh.harvard.edu
   https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
  
  ___
  Freesurfer mailing list
  Freesurfer@nmr.mgh.harvard.edu
  https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Malcolm Tobias
314.362.1594

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

Re: [Freesurfer] Building from source without GUIs

[Malcolm Tobias]

Nick,

While configure now works, I'm getting a build-time error.

It looks like:
histo_register/SimpleBaseLib/include/sbl/image/Image.h

has a dependency on OpenCV.  I didn't see OpenCV listed on the Developers 
Guide:

https://surfer.nmr.mgh.harvard.edu/fswiki/DevelopersGuide

Is this a new dependency?

I tried using --without-opencv but that generated an error with freeview:

make[2]: Entering directory `/export/src/freesurfer-dev-20120106/freeview'
MainWindow.ui -p -o ui_MainWindow.h
make[2]: MainWindow.ui: Command not found

Any suggestions?

Malcolm

On Monday 09 January 2012 13:36:37 Nick Schmansky wrote:
 malcolm,
 
 can you try using the attached configure.in?  you will need to
 run ./setup_configure, which will create a new configure script.
 hopefully --disable-all-apps will then work.
 
 n.
 
 On Mon, 2012-01-09 at 11:51 -0600, Malcolm Tobias wrote:
  Nick,
  
  I'm getting the same error:
  
  [root@login002 freesurfer-dev-20120106]# ./configure --disable-all-apps
  -- disable-gl-apps --disable-tcltk-apps -with-mni-dir=/export/minc-1.4/
  --with- vxl-dir=/export/vxl-1.13.0
  ...
  configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS
  or -- with-BLT-dir.
  
  I've attached the config.log.  Let me know if the mail-list software
  blocks it for any reason.
  
  Cheers,
  Malcolm
  
  On Monday 09 January 2012 11:09:03 Nick Schmansky wrote:
   try addong --disable-tcltk-apps  to your configure command line.
   
   --disable-all-apps appears to be broken.
   
   send me your config.log file if it still doesnt work.
   
   n.
   
   On Mon, 2012-01-09 at 09:51 -0600, Malcolm Tobias wrote:
Nick,

Tcl/Tk is installed on the system under /usr/bin so I can't exclude
it from my path without breaking things.  VTK isn't in my path.

Should the flags to disable the GUI stuff (--disable-all-apps
--disable-gl- apps) be considered broken?  Any other suggestions for
a work-around?  Would a copy of my configure output help?

Malcolm

On Saturday 07 January 2012 14:16:06 Nick Schmansky wrote:
 the other way to build w/o gui support is to exclude the tcl and
 vtk paths in configure.  in other works, only vtk and mni should
 be included in your configure line.
 
 On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
  I'm attempting to build the development branch of the source
  code. To reduce dependencies, I'm trying to build without any of
  the GUI support using the flags:
  
  --disable-all-apps
  --disable-gl-apps
  
  It's complaining about a missing dependency:
  
  configure: error: FATAL: libBLT not found. Check config.log. Set
  LDFLAGS or -- with-BLT-dir.
  
  but the instructions imply that BLT is only necessary for GUIs.
  
  Are there additional arguments that I need to pass to configure?
  
  Malcolm
 
 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 mailing list
   Freesurfer@nmr.mgh.harvard.edu
   https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
  
  ___
  Freesurfer mailing list
  Freesurfer@nmr.mgh.harvard.edu
  https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Malcolm Tobias
314.362.1594

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

Re: [Freesurfer] Building from source without GUIs

[Nick Schmansky]

the other way to build w/o gui support is to exclude the tcl and vtk
paths in configure.  in other works, only vtk and mni should be included
in your configure line.


On Fri, 2012-01-06 at 11:30 -0600, Malcolm Tobias wrote:
 I'm attempting to build the development branch of the source code.
 To reduce dependencies, I'm trying to build without any of the GUI support 
 using the flags:
 
 --disable-all-apps
 --disable-gl-apps
 
 It's complaining about a missing dependency:
 
 configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS or --
 with-BLT-dir.
 
 but the instructions imply that BLT is only necessary for GUIs.
 
 Are there additional arguments that I need to pass to configure?
 
 Malcolm
 

___
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 without GUIs

[Malcolm Tobias]

I'm attempting to build the development branch of the source code.
To reduce dependencies, I'm trying to build without any of the GUI support 
using the flags:

--disable-all-apps
--disable-gl-apps

It's complaining about a missing dependency:

configure: error: FATAL: libBLT not found. Check config.log. Set LDFLAGS or --
with-BLT-dir.

but the instructions imply that BLT is only necessary for GUIs.

Are there additional arguments that I need to pass to configure?

Malcolm

-- 
Malcolm Tobias
314.362.1594

___
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

[Michael Scheel]

Hi everybody,

I have the opportunity to run my analysis with freesurfer on a big  
computer-cluster that is running on AIX.
However to install freesurfer there I need to build it from source. Is  
the source code available?
I found some older entries in the archives and the issue seemed at  
that time rather complicated.

Are there any news regarding building from source?

Thanks, Michael

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

Re: [Freesurfer] building from source

[Pedro Paulo de Magalhães Oliveira Junior]

I have one AIX version. Is it x86?
---
Pedro Paulo de M. Oliveira Junior
Diretor de Operações
Netfilter  SpeedComm Telecom
--- Novo Netfilter 3.0 www.Netfilter.com.br



2009/6/24 Michael Scheel msch...@eyecarecentre.org

 I have the opportunity to run my analysis with freesurfer on a big
 computer-cluster that is running on AIX.

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

Re: [Freesurfer] building from source

[Pedro Paulo de Magalhães Oliveira Junior]

x86 was a typo. I mean POWER5
---
Pedro Paulo de M. Oliveira Junior
Diretor de Operações
Netfilter  SpeedComm Telecom
--- Novo Netfilter 3.0 www.Netfilter.com.br



2009/6/24 Pedro Paulo de Magalhães Oliveira Junior p...@netfilter.com.br

 I have one AIX version. Is it x86?
 ---
 Pedro Paulo de M. Oliveira Junior
 Diretor de Operações
 Netfilter  SpeedComm Telecom
 --- Novo Netfilter 3.0 www.Netfilter.com.br



 2009/6/24 Michael Scheel msch...@eyecarecentre.org

 I have the opportunity to run my analysis with freesurfer on a big
 computer-cluster that is running on AIX.



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