Hi @kwunh,
OK, there’s a lot to unpack here. First off, what version of MRtrix are we talking about? Normally, you would query that using e.g. mrinfo --version, but if you can’t get MRtrix commands to run at all, that’s going to be tricky. You could at least report the location of the commands:
which mrinfo
and the list of libraries that it tries to link to:
ldd $(which mrinfo)
That should give us a clue as to what might be going on.
Next, the ‘symbol lookup error’ that you get references a (pointer to a) function from MRtrix (the MR::ProgressBar::done_func() call, to be precise). So this is not likely to have anything to do with your need to preload libm.so.6 (which is basically version 6 of the C maths library). That doesn’t mean your LD_PRELOAD line isn’t required (though I don’t recommend that approach, see below), only that’s a separate issue.
I’m not sure what might be causing this issue, but in my experience, on any recent version of MRtrix (i.e. within the last 5 years or so), this error would only occur if the build is left in an inconsistent state. For example, MRtrix is built, but then someone checks out a different version and builds only the library, without updating the commands to match. Or someone builds the code from a specific version, then copies that over to the install location, then updates the code to a newer version, builds that, but then only copies over the executables without updating the library (or vice-versa). It should be a trivial matter of running the ./build command again and copying over the results in full (i.e. the full contents of the bin/, lib/ and share/ folders). The commands above should already give us some indications about what’s going on from that point of view.
On a different note: I would personally avoid the LD_PRELOAD trick if at all possible. It will affect all commands you run in that session (not just MRtrix ones), and it really isn’t intended for routine use like that. There are other ways of dealing with this – but it all depends on why this is necessary in the first place. I’d personally recommend investigating a bit more before going ahead with the types of hacks I’m suggesting below. I’m happy to advise, but I’d need a lot more information about the system and environment before making any hard recommendations…
On a cluster, I wouldn’t be surprised if you needed to call module load gcc-XYZ or whichever version of the compiler was used to build MRtrix in the first place – that should set up the environment correctly for MRtrix to run (or maybe you just need to run module load mrtrix3-3.0.4 or something like that if your sysadmins have set that up correctly?).
Failing that, you can always set up a symbolic link to that library in the mrtrix3/lib folder (wherever that may be), since that folder is going to be searched first by the dynamic linker. This has the advantage of only affecting the MRtrix commands (since only these commands would search in that folder, as it should be listed in their run-time search path) – and I’d always favour solutions that leave all other parts of the system unaffected if possible. You should be able to do this with a command like this (assuming you have the required privileges):
ln -sr /opt/glibc/lib/libm.so.6 /path/to/mrtrix3/lib/libm.so.6
Note that you’ll need to edit the /path/to/mrtrix3 bit for that work, and for that, you’ll need to figure out where MRtrix is installed (you can use a command such as which mrinfo to work that out).
Otherwise, there is typically nothing stopping you from building MRtrix within your own account, and keeping it there – this is how I run 99% of the time. No need for admin privileges to do this, unless you also need to install dependencies (basically, a sufficiently recent compiler, assuming you’re not going to be running graphical apps on the cluster). All you’d need to do is make sure that your PATH is set to include the mrtrix3/bin folder (there’s a set_path script included in MRtrix3 to do just that for you).
I hope this helps…
All the best,
Donald.