I've been trying to install BXH/XCEDE tools on my lab's Linux machines, but every C program in the package segfaults every time I try to run it (on every machine in the lab, both 64-bit and 32-bit).

I've tried several versions up through 1.9.9.4, and the issue exists for all of them.

I assume there's some library dependency somewhere that our computers aren't providing...any idea what that could be?

Fedora 14
Kernel 2.6.35.11-83
gcc 5.4.1-4
glib 1.2.10-33
glib2 2.26.0-2
libxml2 2.7.7-3
zlib 1.2.5-2
gdome2 0.8.1-9
libxslt 1.1.26-3

I've also tried compiling from source (using the included config script followed by make), but that fails quickly with
Thanks for any help you can provide.

Originally posted by Erich Greene:
I'm getting the same compilation error on Ubuntu 10.04, gcc 4.4.3

Thanks,

Matthew

Thanks for the reports.  I will be testing on Ubuntu and installing Fedora 14 to see if I can replicate the problem.

I have not yet tested the binaries on Fedora 14, but I have committed several updates that should make it compile with newer gcc compilers.  I will report back on Fedora 14 testing.

On Fedora 14, today's update compiles happily until it gets to docs/usedocs (using the svn update; ./configure --prefix=/path/to/install; make clean all sequence from your thread with Matthew Brett).  I've attached the full output of make, but the exciting bits are

followed by the same errors for several more .xml files, followed by

followed by much looping through the same set of at java.lang... lines, and finally ending in

BUT on the plus side, if I go into the utils directory, the version of bxh_mean runs without segfaulting, so in a pinch, I could move all the new executables to their destinations by hand and call it a win.

Sorry I haven't been able to test on Fedora 14 lately -- the live ISO seems to bomb in VMware after some time which makes it tough to maintain state.  The docs are the last things that are built and not necessary.  So one thing you could try is to add

  --with-xalan-j=/garbage/path

to your configure command, which should ensure that it doesn't try to build the docs.

Once again, sorry I've only been able to work on my end sporadically.

With make tricked into not trying to build the docs, everything compiles and installs fine (at least for 64-bit, I haven't tried 32 yet), and the segfaults are gone.

However, there's a bit of weirdness with fmriqa_qenerate.pl ; when I call it on the .bxh I've created for my test data (with analyze2bxh), the script tries to call bxh_brainmask with the option
  --method=localmin
and bxh_brainmask fails with
> Unsupported mask method 'localmin'

Was there a recent change to bxh_brainmask that didn't propagate up to fmriqa_generate.pl (bxh_brainmask --help only mentions 'threshold' and 'rank' as methods), or should I be thinking user error?

Thanks yet again.

Can you double check whether [lib]gsl was detected during the configure
step? That it necessary for some of the functionality, including the
--localmin option for bxh_brainmask.

After installing gsl and recompiling, the full QA script runs without incident.

Thanks again for all your help.

Hello...

I am aware that this is a very general comment but guess I am trying to figure out how to use these tools...

have been trying to install the tools as downloaded from the website into my laptop MS Win7 (bxh_xcede_tools-1.9.9.5-2-win32.zip) or onto the General Electric's MRI Linux computer (bxh_xcede_tools-1.9.9.4-lsb31.i386.tgz)and cannot manage to run anything.  Is there an easy way to make this work?  

On MS Win7 I get errors related to not finding a library,.. or if found,.. that a routine is not available in another library.  On Linux,... the i386 version does not execute commands.. but with the x86,.. there is an error saying that it does not match the architecture of the machine....

Is there an step by step recipe for dummies that I have missed on the website?

Thanks in advance...

Piotr Wielopolski

Hi Piotr,

Someone else also noticed the missing library on win32 (was it
libxslt.dll?) I have just updated the release on the website -- look
for bxh_xcede_tools-1.9.9.5-3-win32.zip . As far as the Linux version
-- can you provide the output of:

uname -a

and:

lsb_release

(if that command exists). What version of scanner software are you
running? On our GE scanner, I get LSB version 1.3, which is not high
enough to run the tools that I release as binaries (you need at least
3.0). It's been a struggle to get Linux binaries that work on multiple
Linux platforms, and LSB has been the most reliable way, as I can't
manage to get completely static binaries compiled anymore. If our
scanner versions match well enough, I can try to compile and test on
ours and provide a separate release for you.

Oops, make that bxh_xcede_tools-1.9.9.5-4-win32.zip as I forgot
libexslt.dll .

Dear Syam,...

Thanks for including the windows versions with the propper libraries,...(yes, libxslt.dll was the error but the message came out after replacing libxm2.dll by 2 others while testing in the past days). The executables seem  to run wiithout a problem for the moment being.  I have used some of the sample commands described in the wiki regarding the QA evaluation :-)

With regards to the linux installation in the MR scanner,.. the commands that you suggested definitively provide the versions that do not run well with your compilation.   This is the output of the commands (Signa HDxt):

GEHC/CTT Linux 6.3.8
[sdc@lx-mr2 sdc]# uname -a
Linux lx-mr2 2.6.20-1.21 #1 SMP PREEMPT Wed Feb 13 16:59:47 CST 2008 i686 i686 i386 GNU/Linux
[sdc@lx-mr2 sdc]# lsb_release
LSB Version:    1.3
[sdc@lx-mr2 sdc]#

I will switch to the newer GE machines (Discovery 450, 750) but the library is still not usable as per your prior response. This is the output of the newer scanners

GEHC/CTT Linux 5.3.7
[sdc@MR450K08 sdc]# uname -a
Linux MR450K08 2.6.20-1.21 #1 SMP PREEMPT Thu Oct 18 14:27:00 CDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[sdc@MR450K08 sdc]# lsb_release
LSB Version:    1.3

This does not comply either :-(

I have been trying to locate a computer and will install a more propper LINUX release in order to continue with this.....  Coming week an older PC will appear on my desk.  Any good suggestion for a propper LINUX release?  I think I will use a single computer to process the data from multiple scanners rather than having something going wrong in each one of them if there is a software upgrade/or different software versions.  The newer scanners seem to have an older LINUX version than the older scanner??. So, I guess it does not make any sense for you to put more efforts to compile specific versions, I think. 

For the moment, I will play with the windows 7 release, to get used to the commands and outputs generated.  

Thanks again :-)

Piotr

Thanks for providing that info. I have only tested on Red Hat-based
systems (RHEL, CentOS, Scientific Linux, Ubuntu 10.4), and others have
had success with alternative distributions. Fedora 14 seems to have
trouble, and I have not figured out why yet. The important thing to
remember is to install the LSB package if it is not installed by default
-- on Red Hat-based systems it is called redhat-lsb.

This is an old thread, but I seem to have resolved the Fedora 14+ (and maybe other distributions) issue.  For anyone who wants the gory details, basically libxml2 makes some assumptions about the implementation of zlib based on the version of zlib reported in zlib.h; these assumptions are invalid for zlib version 1.2.4 and newer.  Though I build for LSB (Linux Standards Base) 3.1, which includes zlib 1.2.1, the libraries used at runtime might actually be a different version, and LSB is apparently OK with that because the API (or at least the restricted API exported by LSB 3.1) doesn't change.between versions.  Needless to say, libxml2 makes some assumptions that are outside the LSB specification.  I have resolved this by making sure libxml2 compiles and links to a static libz.a (version 1.2.5), and won't ever use a dynamic version.  (Other parts of the system, like dcmtk, will still use whatever libz is available).

Long story short, releases tagged with "lsb31" starting with 1.9.9.5 are expected to work on all LSB 3.1 and newer distributions, even those (like Fedora 14/15/...) that ship with a version of zlib >= 1.2.4.