mrview & shview version mismatch on dev

[Lestropie]

On the current dev branch, I did a full delete of my cmake build directory, a ccache -C, and re-built in a new directory. Commands mrview and shview nevertheless fail to execute due to mismatch between git versions reported for the executable vs. the shared library.

robertes@9520l-003953-l:~/src/mrtrix3$ ldd ./build_cmake/bin/mrview
    libmrtrix-gui.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/src/libmrtrix-gui.so (0x00007fe8e9400000)
    libmrtrix-core.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/core/libmrtrix-core.so (0x00007fe8e9000000)
    libmrtrix-headless.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/src/libmrtrix-headless.so (0x00007fe8e7600000)
    ...
robertes@9520l-003953-l:~/src/mrtrix3$ ./build_cmake/bin/mrview
mrview: [ERROR] executable was compiled for a different version of the MRtrix3 library!
mrview: [ERROR]   mrview version: 3.0.4-708-g895628e0
mrview: [ERROR]   library version: 3.0.4-623-g4f3836b9-dirty
mrview: [ERROR] Running ./build again may correct error

In addition to resolving whatever is causing the conflict, the error message also needs to be updated to reflect the cmake transition.

[daljit46]

My guess is that this is caused by something wrong in your PATH that's somehow preventing a correct selection of the libraries at runtime. I remember @dchristiaens having a similar issue.

[Lestropie]

I've wiped my PATH of all traces of MRtrix3, ensured LD_LIBRARY_PATH is empty, wiped compiler cache, deleted build directory, configured and built:

robertes@9520l-003953-l:~/src/mrtrix3$ ./build_cmake/bin/mrinfo -version
== mrinfo 3.0.4-623-g4f3836b9-dirty ==
...
robertes@9520l-003953-l:~/src/mrtrix3$ ldd ./build_cmake/bin/mrinfo
    libmrtrix-headless.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/src/libmrtrix-headless.so (0x00007fc9fd800000)
    libmrtrix-core.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/core/libmrtrix-core.so (0x00007fc9fd400000)
        ...
robertes@9520l-003953-l:~/src/mrtrix3$ ./build_cmake/bin/shview -version
shview: [ERROR] executable was compiled for a different version of the MRtrix3 library!
shview: [ERROR]   shview version: 3.0.4-711-g81d8576d-dirty
shview: [ERROR]   library version: 3.0.4-623-g4f3836b9-dirty
shview: [ERROR] Running ./build again may correct error
robertes@9520l-003953-l:~/src/mrtrix3$ ldd ./build_cmake/bin/shview
    libmrtrix-gui.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/src/libmrtrix-gui.so (0x00007ff5bc600000)
    libmrtrix-core.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/core/libmrtrix-core.so (0x00007ff5bc200000)
    libmrtrix-headless.so => /home/unimelb.edu.au/robertes/src/mrtrix3/build_cmake/src/libmrtrix-headless.so (0x00007ff5ba800000)
        ...
robertes@9520l-003953-l:~/src/mrtrix3$ git describe --abbrev=8 --dirty --always
3.0.4-711-g81d8576d-dirty

So it seems to me that only the GUI executables are capturing the correct version identifier; the headless binaries and the shared libraries are all capturing some incorrect version, but because it's the same incorrect version, execution there is successful.

[daljit46]

Hmm, that's very strange. I cannot reproduce this on my system (Ubuntu 22.04 LTS). @MRtrix3/mrtrix3-devs does anyone else have the problem?

[Lestropie]

Is it only the version mismatch for GUI commands that you're unable to replicate? Because that's downstream of the fact that all headless commands are reporting an incorrect version. Whether or not other people observe that issue will be the first determination of where to be looking for a problem.

Also, I can grep for the SHA1 commitish that the headless commands are reporting, and it doesn't appear to be stored anywhere. So I've no idea where it's even getting that version info from.

[Lestropie]

Some relevant notes in #2829.

It seems to me the issue is that if one is not doing a clean clone + configure + build on a cmake-based branch, but is switching between different development branches inluding some pre-cmake (potentially for the sake of merging to cmake-transformed dev), then in some instances files core/version.cpp & src/exec_veresion.cpp intertwined with the source code generated by the old build script may be left lying around, and the compiler may be grabbing those rather than the versions that cmake generates within the build directory. Totally agree that having such files generated separately to the source code makes perfect sense; but could cause grief for any branch-hoppers.

We've encountered not entirely dissimilar situations in the past, in terms of derivatives of prior versions of the build system being explicitly swept away so as not to corrupt the build system under invocation. I think something similar would make sense here. Explicitly deleting files core/version.cpp and src/exec_version.cpp from the source code may not be considered kosher in cmake-land. Perhaps what we need instead is some explicit detection of the presence of those two files in the source tree, and their exclusion from compiler / linker invocations.

(Indeed I suppose that if we had no globbing, and every source file were explicitly listed in CMakeLists.txt, this probably wouldn't arise)

[daljit46]

Perhaps what we need instead is some explicit detection of the presence of those two files in the source tree, and their exclusion from compiler / linker invocations.

I'm not sure that this is a good idea to be honest. It seems to me the issue is fundamentally due to our old build system having no distinction between source directory and build directory. I can't remember if this is the case, but my guess is that if you run build clean those generated files should be deleted right? If yes, then I think this problem can be dealt manually fairly easily.

[Lestropie]

if you run build clean those generated files should be deleted right?

Yes; though if you've already transitioned to a cmake-based branch, ./build clean won't be accessible. Also, from memory directly deleting those files wasn't sufficient, as cmake had already pre-configured to use them; it required wiping the build directory and starting fresh. Assuming that there isn't some other clever way of dealing with this (eg. flagging within git that any file at that path should be deleted if it exists), it might just be a case of diligence. Though I think the error message should at least be updated to reflect what now has to be done in such an occurrence.

[Lestropie]

Closed by #2854.