binaries not running or compiling in High Sierra

[drmarcj]

Several tools won't work in MacOS 10.13.x because the precompiled .mexmaci64 files will not run. In some cases they fail silently, leading to obscure errors (e.g., "invalid number of parameters"). The issue arises in both an older and newer version of Matlab (2014a and 2017b).

Sadly, whatever breaks the binaries also breaks the ability to re-compile them - I suspect Apple has updated Developer Tools with some syntax changes. For example:

mex -O -I./jama dtiFiberTracker2.cxx

[...]

/Users/marcj/Documents/MATLAB/vistasoft/mrDiffusion/src/dtiFiberTracker2.cxx:619:14: error: cannot initialize a variable of type 'const int ' with an rvalue of type 'const size_t ' (aka 'const unsigned long ') const int dt6Dims = mxGetDimensions(prhs[0]); ^ ~~~~~~~~ /Users/marcj/Documents/MATLAB/vistasoft/mrDiffusion/src/dtiFiberTracker2.cxx:620:14: error: cannot initialize a variable of type 'const int ' with an rvalue of type 'const size_t ' (aka 'const unsigned long ') const int seedDims = mxGetDimensions(prhs[1]); ^ ~~~~~~~~

I did try tweaking the code a little to cast the 'int' as 'mwSize *dt6Dims' and so on, which just kicks up other errors further on again having to do with variables type mismatches. I just gave up at that point and am running Vistasoft tools on an older Mac. But this may be an ongoing problem if the problem is indeed due to High Sierra (which seems to be the common denominator among systems giving me this grief - works great in 10.11 and Ubuntu Linux 14.04 LTS).

-Marc-

[JWinawer]

Hi Marc,

Can you let us know which binaries are not working for you? Is it only dtiFiberTracker2?

I run MacOS 10.13.x and have not run into this problem, except for the one that was fixed some time back. In fact, the binary problem that was fixed sounds similar to the one you observed. See this earlier issue: https://github.com/vistalab/vistasoft/issues/239

More generally, we can catch these issues pretty easily with validation functions when we have them. Currently, there are many validation functions for fMRI, and these tests all pass on MacOS10.13.

Unfortunately, we do not yet have validation test functions for diffusion.

Jon

[drmarcj]

Hi Jon Thanks for the reply. I'm only working with mrDiffusion right now (trying to get AFQ to work on my MacOS box - works well on Linux and other MacOS computers not running 10.13). The binaries that don't work are vistasoft/mrDiffusion/src/*.mexmaci64 but I'm guessing the other mexmaci64 binaries are equally affected.

I just tried cloning a clean vistasoft and running dtiFiberUI. It is still unhappy:

An error occurred in mrDiffusion: Invalid MEX-file '/Users/marcj/Documents/matlab/vistasoft/mrDiffusion/src/dtiSplitTensor.mexmaci64': dlopen(/Users/marcj/Documents/matlab/vistasoft/mrDiffusion/src/dtiSplitTensor.mexmaci64, 6): Library not loaded: @loader_path/libmex.dylib Referenced from: /Users/marcj/Documents/matlab/vistasoft/mrDiffusion/src/dtiSplitTensor.mexmaci64 Reason: image not found. Thrown in: /Users/marcj/Documents/matlab/vistasoft/mrDiffusion/file/dt6/dtiLoadDt6Gui.m line 69

Also if I check library dependencies with otool here's what I get:

otool -L /Users/marcj/Documents/matlab/vistasoft/mrDiffusion/src/dtiSplitTensor.mexmaci64 /Users/marcj/Documents/matlab/vistasoft/mrDiffusion/src/dtiSplitTensor.mexmaci64: @loader_path/libmx.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libmex.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libmat.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

Some of the .c files will compile with mex but others won't. For example dtiSplitTensor will compile, but dtiFitTensor will not. Here's the error it throws:

/Users/marcj/Documents/MATLAB/vistasoft/mrDiffusion/src/dtiFitTensor.c:594:5: error: void function 'mexFunction' should not return a value [-Wreturn-type] return 0;

Anyway: I hope this gives you something to go on. FYI I'm running High Sierra 10.13.4, 64-bit (Macbook Pro 13" late 2013 model), Xcode 9.3.

Cheers,

-Marc-

On Sun, Jun 3, 2018 at 6:06 PM Jonathan Winawer notifications@github.com wrote:

Hi Marc,

Can you let us know which binaries are not working for you? Is it only dtiFiberTracker2?

I run MacOS 10.13.x and have not run into this problem, except for the one that was fixed some time back. In fact, the binary problem that was fixed sounds similar to the one you observed. See this earlier issue:

239 https://github.com/vistalab/vistasoft/issues/239

More generally, we can catch these issues pretty easily with validation functions when we have them. Currently, there are many validation functions for fMRI, and these tests all pass on MacOS10.13.

Unfortunately, we do not yet have validation test functions for diffusion.

Jon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vistalab/vistasoft/issues/295#issuecomment-394195321, or mute the thread https://github.com/notifications/unsubscribe-auth/ADc1FkGYFqJPk5-Igs4y7URxf5XE1zHuks5t5F3ygaJpZM4UQfyV .

[andrew-taylor-2]

Hello,

I ran "mex -compatibleArrayDims -O -I./jama dtiFiberTracker.cxx", which compiled while "mex -O -I./jama dtiFiberTracker.cxx" did not. I don't know much about the flag that I used -- will my binary now work as intended? Or did I change the function of the code with this flag?

Thanks for reading!

[andrew-taylor-2]

I also faced the problem with "mexFunction should not return a value". It looked like incorrectly written C to me. The return 0 is only used when the wrong number of inputs is given -- and I'm using this function within the somewhat stable AFQ pipeline, so I changed this to simply "return;". I then had to add " -lmwlapack -lmwblas" to my mex compile command to get it working properly. I got this idea from "dtiCompileMex.m"

[Youguang]

-lmwlapack -lmwblas worked for ndfun.c, this may help.

[andrew-taylor-2]

Hello! Glad that helped you. Also, not to alarm anyone but: if you're compiling to a 64bit architecture, I think you should always use "-compatibleArrayDims". There were two (I think) vistasoft functions which gave errors if I didn't include the flag, but there was one function that didn't give an error at compile time, but did at runtime. Setting the flag seems to have fixed this.

For reference, it was dtiSplitTensor.c. The offending line was

const int *dimsPtr = mxGetDimensions(prhs[0]);

Later, the dimension check

if (dimsPtr[3]!=6)

failed because it thought my 4th dimension was 0... when it was definitely 6.

Anyway, this is all just educated guessing since I don't write C and I'm not well versed on mex function history.

Edit: It seems like the best solution would be to change some variable declarations like so https://stackoverflow.com/questions/43045701/switch-compiler-on-matlab-2017a-in-ubuntu-os

-Andrew

[Youguang]

@andrew-taylor-2

Thanks for your reminder.

I tested with -compatibleArrayDims, but when call "ndfun.mexmaci64", Matlab(2019a, Mac 10.14) crashed! But the no -compatibleArrayDims version worked well.