I’m trying to compile mrtrix3 on a RedHat 7 server. I’ve compiled gcc 4.9.2 in /usr/local/ and use an export CXX statement to point the configuration script to it, but then when I run
./configure -nogui
I get the error
"ERROR: unable to determine pointer size!"
and it recommends that I check the configure.log file for more details. In the configure.log file the relevant section is:
EXEC <<
CMD: /usr/local/bin/gcc /tmp/tmpX1oe_W.o -pthread -o a.out
EXIT: 1
STDERR:
/tmp/tmpX1oe_W.o: In function `main':
tmpX1oe_W.cpp:(.text+0xc): undefined reference to `std::cout'
tmpX1oe_W.cpp:(.text+0x14): undefined reference to `std::ostream::operator<<(unsigned long)'
/tmp/tmpX1oe_W.o: In function `__static_initialization_and_destruction_0(int, int)':
tmpX1oe_W.cpp:(.text+0x44): undefined reference to `std::ios_base::Init::Init()'
tmpX1oe_W.cpp:(.text+0x59): undefined reference to `std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status
>>
error deleting temporary file "a.out": No such file or directory
ERROR: unable to determine pointer size!
Every other test returns 0 as the exit code.
Any thoughts on what could be wrong?
The mesa opengl library yum install didn’t work, so maybe there’s a missing dependency there, but I had assumed it was just for the GUI.
Yes, that looks like a similar problem to this thread, which is basically an incomplete compiler installation. In your case, the compiler executable is in a non-standard location, and when it tried to link the final executable with the c++ libraries, it can’t find the correct version of it because their location isn’t in the linker search path. Working with custom compilers can be a bit tricky from that point of view, and getting it right would require setting the correct CXX, CFLAGS, and LDFLAGS, in your case probably like this:
You may find that’s sufficient to compile – but probably not to run anything you’ve just compiled, which is still required for the configure step. For that, you’d need to set the path for the dynamic linker. The simplest way to do this is probably:
export LD_LIBRARY_PATH=/usr/local/lib
With that, you might be able to run through the configure and build steps.
If that works, you’ll also need to set the LD_LIBRARY_PATH variable before invoking any of the newly generated executables… However, as I’d hinted in the previous thread, that’s generally discouraged, the better way to set the linker search path is by adding an entry to /etc/ld.so.conf.d/, as explained e.g. here.
If all else fails, you could try this script, which I’ve put together based on these instructions (from @rsmith), which might get you most of the way - but it does involve building all dependencies from source, which is a fair bit more involved than might be required in your case…
I successfully ran ./configure and ./build,
but now if I run a program as a user, I get the following error from dwidenoise:
dwidenoise: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20’ not found (required by /usr/local/mrtrix3/bin/…/lib/libmrtrix-3.0_RC2.so)
I’m not very familiar with the details of how C++ compiled programs work, so I’m not sure what’s gone wrong. I would have thought that such an error would have occurred at build time.
Additionally, I tried running configure with the -static option, and this gave me a “no suitable compiler found” error, despite the fact that it works fine without the -static option. I thought that trying a static build would get rid of the runtime error, but that just won’t build at all.
As I’d hinted above (not very obvious, I’ll admit), you need to do something to inform the runtime linker of the location of your compiler’s libraries. Here, it’s clear that the standard C++ libraries used by your executables are the system’s default ones, not the ones you just installed to /usr/local/ - hence the version mismatch.
See what I’d suggested earlier on that topic – this relates to exactly this issue:
Compiling static executables is such a rare requirement, it’s unfortunately quite poorly supported. What’s needed for this to work are static versions of all libraries needed. These are typically files like libstdc++.a, where the dynamic (shared) version of that library would be libstdc++.so. This applies to all required libraries, including libm, libz, and if compiling with Qt, static versions of all its libraries. No simple task, unfortunately.
This typically works using the system compiler, and a decent recent distribution might also include all the static versions of the required libraries, so things typically work out of the box (although it’s very rare for the static version of Qt to be included). For a custom built compiler, you’d probably need to set it up for static linking when you configure it (before compiling it) – there’s probably an option for it, but it’s not something I’ve ever done…
I gave up on a static build, but I did end up getting it to work by simply copying the libstdc++.so.6 file into the mrtrix3 lib directory. I don’t believe that I used that LD_LIBRARY_PATH command, but if I run into the issue again I’ll give it a whirl.
Yes, that’s more or less the approach I’d suggested in the thread I mentioned earlier – although I would insert a symbolic link to the library, rather than a full copy: