Error processing project file: /tmp/tmpeXDMTO/

I am getting error as below while running command ,/configure.

…DQ67SW:~/mrtrix3$ ./configure

MRtrix build type requested: release

Detecting OS: linux
Checking for C++11 compliant compiler [g++]: 4.8 - tested ok
Detecting pointer size: 64 bit
Detecting byte order: little-endian
Checking for variable-length array support: yes
Checking for non-POD variable-length array support: yes
Checking for zlib compression library: 1.2.8
Checking for Eigen 3 library: 3.2.0
Checking shared library generation: yes
Checking for Qt moc: moc (version 4.8.5)
Checking for Qt qmake: qmake (version 4.8.5)
Checking for Qt rcc: rcc (version 4.8.5)
Checking for Qt:
ERROR: qmake returned with error:

QMAKESPEC has not been set, so configuration cannot be deduced.
Error processing project file: /tmp/tmpqum2CE/


This can be an annoying problem… In general, it’s more a reflection that the necessary bits of Qt aren’t all installed, or not configured properly, or there’s several versions hanging around and conflicting with each other. See this old post for some possible suggestions.

I’m guessing this is an Ubuntu 14.04 system? You’d need to look through your configure.log file for hints as to what might be going wrong. Feel free to post it here if you need help (use the [code][/code] tags to keep things clean).

Dear MrTrix3 user community:

I am not sure whether this has been solved or not yet, but I have encountered the identical issue. I am using Ubuntu 14.04. This is a first post for me and I am not fully familiar with the text coding system, and if I messed it up, I am sorry.


Following is the configure.log file, which will be relevant.

REPORT: Checking for Qt moc:
CMD: moc -v
Qt Meta Object Compiler version 63 (Qt 4.8.6)

REPORT: moc (version 4.8.6)

REPORT: Checking for Qt qmake:
CMD: qmake -v
QMake version 2.01a
Using Qt version 4.8.6 in /usr/local/anaconda/lib

REPORT: qmake (version 4.8.6)

REPORT: Checking for Qt rcc:
CMD: rcc -v
Qt Resource Compiler version 4.8.6

REPORT: rcc (version 4.8.6)

REPORT: Checking for Qt:

source file "qt.h":

#include <QObject>

class Foo: public QObject {
  public slots:
    void setValue(int value);
    void valueChanged (int newValue);
    int value_;

source file "qt.cpp":
#include <iostream>
#include "qt.h"

Foo::Foo() : value_ (42) { connect (this, SIGNAL(valueChanged(int)), this, SLOT(setValue(int))); }

Foo::~Foo() { std::cout << qVersion() << "\n"; }

void Foo::setValue (int value) { value_ = value; }

int main() { Foo f; }

project file "":
CONFIG += c++11
QT += core gui opengl svg
HEADERS += qt.h
SOURCES += qt.cpp
CMD: qmake
QMAKESPEC has not been set, so configuration cannot be deduced.
Error processing project file: /tmp/tmpou_TdJ/

ERROR: qmake returned with error:

QMAKESPEC has not been set, so configuration cannot be deduced.
Error processing project file: /tmp/tmpou_TdJ/

ERROR: unexpected exception!

  See the file 'configure.log' for details. If this doesn't help and you need
  further assistance, please post on the MRtrix3 community forum
  (, and make sure to include the full contents of
  the 'configure.log' file.

I think this is the problem:

Using Qt version 4.8.6 in /usr/local/anaconda/lib

Your anaconda install is conflicting with your actual Qt installation. This is a problem that occurs fairly frequently, we had a chat about this recently with @dchristiaens. I have no idea why anaconda ships with the Qt compile-time utilities (there won’t ever be a need for it for users), and even if they insist on doing so, it’s frankly inconsiderate to add these tools to the default PATH, overriding the default Qt install, and no doubt causing this kind of trouble for anyone that happens to develop with Qt. If anyone wants to get in touch with the anaconda project to maybe suggest not needlessly polluting people’s systems with conflicting versions of Qt, or at the very least not placing them in the default PATH, you have my blessing…

OK, having got this off my chest (apologies about the rant), the simplest way to fix this is probably to make sure your system’s genuine Qt utilities appear first in the PATH. If you can figure out where your genuine version of Qt installed its version of these executables (typically /usr/bin), you can modify your PATH such that that location appears first, using e.g.:

export PATH=/usr/bin:$PATH

Then try ./configure again. That ought to allow you to compile MRtrix3

The alternative is to remove the offending anaconda folder from your PATH temporarily before you invoke ./configure. This is a touch more involved, but probably also informative. Simplest way to do this is to first print out the current PATH:

echo $PATH

Then type the following (don’t press return yet):

export PATH=

and copy/paste the output of the previous command after it, then edit the line to remove the bits that mention anaconda. Press return and try ./configure again.

But really, it would be so much simpler if the anaconda project simply kept its (unnecessary) Qt development utilities away from the default PATH…

I agree with @jdtournier, it would be much simpler if Anaconda would isolate its Qt binaries in a separate folder, but they choose to put everything in one single folder. If you then want to use anaconda/bin/python instead of /usr/bin/python, but at the same time want to use /usr/bin/qmake instead of anaconda/bin/qmake, you’re stuck…

The fix I went for is Donald’s second suggestion, i.e., to strip PATH of all references to anaconda before running ./configure. Luckily, you don’t need to repeat this each time you update and run ./build. But you will need to remember this every time you reconfigure, which is unfortunate…

Another solution I can think of, would be to permanently remove anaconda from your path all together, and symlink only the binaries that you actually want to use ( python, ipython, etc.) from /usr/local/bin.

Hello @jdtournier @dchristiaens,

Thank you very much for your quick reply and suggestions.
I have tested the suggestion you mentioned, and now ./configure works in my computer. I could build MrTrix 3 now.

Certainly the conflict between anaconda is an annoying issue, and I hope that the issue will be fixed in the future.

Again, thank you very much for your helpful reply.

A workaround that worked for my Linux machine (Ubuntu 16.04) was to change

export PATH="/home/lgianca/anaconda2/bin:$PATH"


export PATH="$PATH:/home/lgianca/anaconda2/bin" 

in ~/.bashrc

Be aware that this will give precedence to the machine-wide python packages (if you have it installed) over the one’s provided by Anaconda.

I hope this helps other people running into the same problem.