I am trying to install mrtrix3 on a ubuntu 16.04 cluster, and I can’t get past this step:
$ ./configure -static
Traceback (most recent call last):
File “./configure”, line 231, in
if noshared: build_options.application (‘noshared’)
AttributeError: ‘list’ object has no attribute ‘application’
$ ./configure -static -nogui
Traceback (most recent call last):
File “./configure”, line 231, in
if noshared: build_options.application (‘noshared’)
AttributeError: ‘list’ object has no attribute ‘application’
I’m not an expert in the internals of the configure script, but having a quick look at the reported line 231 in there, I’ve got the feeling this can be explained by a typo in the script itself, and is specific to the use of the -static build option. That part (the whole block/“paragraph” of code in that bit of configure) only got introduced relatively recently (https://github.com/MRtrix3/mrtrix3/commit/09363c46c2ca838826959535286f048a2764f59e ; Feb 21), and furthermore only got “released” to most of our users last Friday, when the 3rd release candidate (RC3) became available. So I’m not surprised you’d be the first person running into this.
I think this should resolve your issue: open the “configure” script/file in your main MRtrix3 folder directly in any simple text editor, go to line 231, which should read:
if noshared: build_options.application ('noshared')
…and change this line to:
if noshared: build_options.append ('noshared')
…and save those changes to the file. Then, simply try running ./configure -static -nogui again.
The use of the -nogui option (or not using it) is not related to this particular issue, but since you’re installing to a cluster, you probably want to supply that option nonetheless. There’s (probably) no use to having mrview being build and sitting on your cluster, and it would require a few dependencies related to graphical stuff which probably also don’t make a lot of sense to have installed on a cluster.
@jdtournier, correct me if I’m wrong in any of the above. Also, if correct, then this is a bug we’d need to fix of course.
Thanks, it looks like changing the ./configure to use the append worked. Now i see:
$ ./configure -static -nogui
MRtrix build type requested: release version with nogui, noshared, static
Detecting OS: linux
Looking for compiler [clang++]: not found
Looking for compiler [g++]: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Checking for C++11 compliance: ok
Detecting pointer size: 64 bit
Detecting byte order: little-endian
Checking for variable-length array support: ok
Checking for non-POD variable-length array support: ok
Checking for ::max_align_t: 16 bytes
Checking for std::max_align_t: 16 bytes
Checking for Eigen3 library:
ERROR: error compiling Eigen3 application!
MRtrix3 was unable to compile a test program involving Eigen3.
Set the EIGEN_CFLAGS environment variable to inform ‘configure’ of
the flags it must provide to the compiler in order to compile
programs that use Eigen3 functionality; this may include the path to
the Eigen3 include files, as well as any required flags.
For example:
$ export EIGEN_CFLAGS="-isystem /usr/include/eigen3"
$./configure
(amend with the actual path to the Eigen3 include files on your system)
I know that eigen3 is a dependacy, but i thought building it this way didn’t require me to do an apt install of libeigen3-dev.
Is there something else that needs to be changed so it would work?
libeigen3-dev is indeed a dependency… so I suppose apt install-ing that one should solve it. Any reasons why you’d want to avoid apt install-ing it? Otherwise, the solution is what the configure script suggests at the end:
That would be if you’ve stored those files somewhere else “manually” (e.g. in scenarios where you didn’t apt install it, but downloaded and stored it somewhere yourself). Run that “export” line right before your configure command, and you should also be fine.
Just to clarify a few things, since there seems to be a bit of confusion here:
a static build is an independent concept from the standalone package.
The static build means that the executables, once compiled, will not require external libraries to run. But you still need all the compile-time dependencies to generate these executables in the first place – i.e. during the ./build.
the standalone packager operates after a successful build (static or not). What it does is figure out what libraries are needed at runtime for the executables to function, and tries to include them alongside the executables to guarantee that they will be present at runtime, once you’re installed the package on some other system. It makes no sense to use it for a static build, since the executables don’t rely on external libraries anyway (and the packager will most likely fail in this case).
in both cases, you need all the compile-time dependencies to be present during the build. What both the static build and standalone packager provide is a means of limiting or removing the dependence of the install on external dependencies on a different target system – i.e. they make sense when you’re trying to install on an old system where these dependencies aren’t available (e.g. an HPC cluster), by building the programs on a more modern system where the dependencies are available and transferring all the functionality across.
OK, this steps literally only needs to find and run qmake, which is an executable provided by Qt, necessary to figure out the right flags to compile with Qt. If it’s not finding it, the most likely reason is that it’s not in your PATH. If you simply type qmake at the terminal, does it print out a help page, or ‘command not found’? If the latter, you need to amend your PATH to include the location of the qmake executable (which hopefully will also include moc and rcc, required later on). You should be able to do this with (amend as appropriate, obviously):
However, there’s a good chance this might still not work if you’re trying to generate a static build. My guess is configure will fail a bit later, when trying to compile a small test Qt application. If you really need to compile a static build, you’ll need to get your hands on a static build of Qt as well (i.e. you need to link to libQt5Core.a rather than libQt5Core.so, etc). I’ve not come across one so far… I think to do this, you’ll need to build Qt itself manually as a static version. There’s some instructions for doing this on the Qt website – but it’s no mean feat, as far as I can tell. At this point, you’re very much on your own…