Hi @ewing,
OK, these issues can indeed get pretty messy – especially when anaconda is in the mix, since it makes all kinds of subtle behinds-the-scenes changes that can be pretty difficult to track down…
There are really two issues here, but they may be the same issue – it depends on how clever the system is. Let’s start with the second one, since that one really should work properly; that’s the one with ‘error while loading shared libraries’.
First thing to check, which libraries does tensor2metric require:
$ ldd /software/mrtrix3/bin/tensor2metric
On my system, this gives:
$ ldd ~/mrtrix3/bin/tensor2metric
linux-vdso.so.1 (0x00007f9ccfcc7000)
libmrtrix.so => /home/donald/mrtrix3/bin/../lib/libmrtrix.so (0x00007f9ccf800000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f9ccf400000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f9ccfb6c000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9ccfb47000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f9ccf21e000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9ccfcc9000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f9ccfb2d000)
libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007f9ccf772000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f9ccf738000)
libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007f9ccf14b000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f9ccf705000)
libjbig.so.2.1 => /usr/lib/libjbig.so.2.1 (0x00007f9ccfb1e000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007f9ccf09f000)
In your case, I expect it’ll report:
libmrtrix.so => not found
somewhere in the mix…
Assuming that’s the case, we next need to figure out where the system is looking for libraries when loading the executable. There are two sources for this information: the system linker search path, and the executable’s own runpath (which we have baked into the executable itself). To query these, you can use:
-
For the system linker search path (this is for reference, it really shouldn’t be relevant here):
ldconfig -v 2>/dev/null | grep ^/
On my system, this gives:
$ ldconfig -v 2>/dev/null | grep ^/
/usr/lib/R/lib: (from /etc/ld.so.conf.d/R.conf:1)
/usr/lib/libfakeroot: (from /etc/ld.so.conf.d/fakeroot.conf:1)
/usr/lib/octave/8.3.0: (from /etc/ld.so.conf.d/octave.conf:1)
/usr/lib: (from <builtin>:0)
These are the folders where the system will look for all the different libraries. If you look in those folders, you should find a large number of .so files – these are libraries, aka shared objects – what would be called a DLL (Dynamically Linked Library) on Windows, or a .dylib (Dynamic Library) on macOS.
You really shouldn’t find libmrtrix.so in those folders, unless someone has done something really strange…
-
for the executable’s runpath (this is the relevant one for MRtrix):
readelf -d /software/mrtrix3/bin/tensor2metric | grep RUNPATH
On my system, this gives:
$ readelf -d ~/mrtrix3/bin/tensor2metric | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib]
which is as expected: we have compiled our code to expect the MRtrix library to be located in the lib/ folder next to the command’s own bin/ folder – i.e. in .../lib relative to the executable.
At this point, you can look in the folder specified in the runpath, which in your case can be done with:
ls -l /software/mrtrix3/lib
On my system, this gives:
$ ls -l ~/mrtrix3/lib/
total 3572
-rwxr-xr-x 1 donald donald 3653096 Oct 9 13:53 libmrtrix.so
drwxr-xr-x 7 donald donald 4096 Jan 19 2023 mrtrix3
And you can see that the libmrtrix.so file is indeed in the expected location (along with the mrtrix3 folder, which contains our Python libraries).
The final bit to check is that the permissions for the MRtrix library are set correctly, so it is marked as executable – otherwise the system won’t allow the code it contains to be executed. In the above you can see the 3 “x” in the permissions section of the output for libmrtrix.so, which indicates that it’s executable for everyone on the system (see e.g. here for a breakdown on how to interpret Unix permissions).
If all of the above checks out, then I really can’t understand why this doesn’t work… But my guess is your sysadmin may have omitted to copy over the lib/ folder when installing (see this document for details on deployment), or somehow reset the permissions on the library when copying it across. But you’ll need to look for yourself to find out…
For the other issue (that it defaults back to the anaconda install), one possibility might be that the system is smart enough to not even try to run the new version as it can already detect that it can’t find the libmrtrix.so library, and so skips to the next available executable it can find with the same name…
Otherwise, there is a faint chance you may not have set the PATH correctly – check with:
$ echo $PATH
Note that it needs to contain the /software/mrtrix3/bin folder – not just /software/mrtrix3. But I doubt that’s the issue – worth double-checking nonetheless…
OK, that should already give you plenty of information to try to figure this out. Let me know how you go!
All the best,
Donald.