Closed zmichels closed 6 years ago
There should not be a problem with Matlab 2017a. Maybe you can debug where exactly it hangs?
I am not sure how to debug where it hangs, but I can share the following details. I have both Matlab 2015a and 2017a on my machine. I have disabled SIP on my mac (went through the procedure again to be sure). I can install any of the downloads on my 2015a installation. None of the downloads will install on my 2017a. On my 2017a install, when I type “startup_mtex”, the message says initializing… but it never gets past that. On my 2015a install, I do the same thing and MTEX is initialized and installed in a heartbeat. Additionally, after trying to install on 2017a, Matlab becomes unusable because it is stuck trying to initialize mtex. I force quite the application and restart it, but it automatically starts trying to initialize mtex again (and gets stuck again). SO i change the folder name of mtex or delete in and restart 2017a again, and then it breaks free of the loop because it can’t find the folder. I have none of these issues with 2015a. I can continue using 2015a for now, but any thoughts on how to eventually get it working with 2017a would be greatly appreciated. screenshot is of where it hangs.
best, Zach [cid:8A5B7A7E-7934-4BA6-98D7-28E4EC4937CB@eau.wi.charter.com]
On Mar 16, 2017, at 3:11 AM, Ralf Hielscher notifications@github.com<mailto:notifications@github.com> wrote:
There should not be a problem with Matlab 2017a. Maybe you can debug where exactly it hangs?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-286985812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQUw05mqp3NrMgFR7QCYGE3QmEvT_oks5rmO68gaJpZM4MdLzj.
I also tried the solution mentioned for which the users had success by copying libfftw3.3dylib and libnfft3.1.dylib files from (mtex)/c/bin/maci64/ to /opt/local/lib This did not change the result – still hangs and never installs mtex on 2017a.
On Mar 16, 2017, at 3:11 AM, Ralf Hielscher notifications@github.com<mailto:notifications@github.com> wrote:
There should not be a problem with Matlab 2017a. Maybe you can debug where exactly it hangs?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-286985812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQUw05mqp3NrMgFR7QCYGE3QmEvT_oks5rmO68gaJpZM4MdLzj.
Hi Zach, I think I know what might be happening.
startup_mtex
calls check_installation
which has a function check_mex
which itself calls fast_check_mex
. This one tests whether mex-files are working/installed using dot_outer
which itself uses SO3Grid_dist_region
which is a mex file and this one hangs indefinitely without coming back to tell anybody what is happening, hence it will never finish the test to tell that we should try to recompile the mex files.
For me it worked to re-compile the mex files. Run within c/mex mex_install
and re-run startup_mtex
.
This is on osx10.95 and Matlab 2017a. Seems to be an Apple only issue, no problems elsewhere.
Does that work?
Cheers,
Rüdiger
Edit: newly compiled mex files seem to be backwards compatible, at least till 2016b, but I have nothing older to test.
Hi Rüdiger,
Thanks for the suggestion. I tried to run mex_install within the c/mex directory, and I specified my mtex_path. This procedure returns an error message:
"Undefined function or variable 'newer_version'.
Error in mex_install (line 9) if nargin <= 2 && newer_version(7.3)”
Seems mundane, but I am not sure exactly where to set this variable. So, instead, I tried compiling the MEX files individually to see what would happen. 7 of the 11 .C/MEX files compile successfully, but 4 do not... and those 4 return an identical error.
The files MEX files that compile successfully are: S1Grid_find.c S1Grid_find_region.c S2Grid_find.c S2Grid_find_region.c SO3Grid_dist_region.c SO3Grid_find.c SO3Grid_find_region.c
The files that Do NOT compile are: buffer.c S1Grid.c S2Grid.c SO3Grid.c
These all return an error that reads:
"Error using mex Undefined symbols for architecture x86_64: "_mexFunction", referenced from: -exported_symbol[s_list] command line option ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)”
When I run: mex buffer.c -v I get the following details from the verbose mode
“
mex buffer.c -v Verbose mode is on. ... Looking for compiler 'Xcode with Clang' ... ... Looking for environment variable 'DEVELOPER_DIR' ...No. ... Executing command 'xcode-select -print-path' ...Yes ('/Applications/Xcode.app/Contents/Developer'). ... Looking for folder '/Applications/Xcode.app/Contents/Developer' ...Yes. ... Executing command 'which xcrun' ...Yes ('/usr/bin/xcrun'). ... Looking for folder '/usr/bin' ...Yes. ... Executing command 'defaults read com.apple.dt.Xcode IDEXcodeVersionForAgreedToGMLicense' ...No. ... Executing command 'defaults read /Library/Preferences/com.apple.dt.Xcode IDEXcodeVersionForAgreedToGMLicense' ...Yes ('8.0'). ... Executing command ' agreed=8.0 if echo $agreed | grep -E '[.\"]' >/dev/null; then lhs=
expr "$agreed" : '\([0-9]*\)[\.].*'
rhs=expr "$agreed" : '[0-9]*[\.]\(.*\)$'
if echo $rhs | grep -E '[."]' >/dev/null; then rhs=expr "$rhs" : '\([0-9]*\)[\.].*'
fi if [ $lhs -gt 4 ] || ( [ $lhs -eq 4 ] && [ $rhs -ge 3 ] ); then echo $agreed else exit 1 fi fi' ...Yes ('8.0'). ... Executing command 'xcrun -sdk macosx --show-sdk-path' ...Yes ('/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'). ... Executing command 'xcrun -sdk macosx --show-sdk-version' ...Yes ('10.12'). Found installed compiler 'Xcode with Clang'. Options file detailsCompiler location: /Applications/Xcode.app/Contents/Developer Options file: /Applications/MATLAB_R2017a.app/bin/maci64/mexopts/clang_maci64.xml CMDLINE200 : /usr/bin/xcrun -sdk macosx10.12 clang -Wl,-twolevel_namespace -undefined error -arch x86_64 -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -bundle -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o -O -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/c_exportsmexfileversion.map" -L"/Applications/MATLAB_R2017a.app/bin/maci64" -lmx -lmex -lmat -lc++ -o buffer.mexmaci64 CC : /usr/bin/xcrun -sdk macosx10.12 clang CXX : /usr/bin/xcrun -sdk macosx10.12 clang++ DEFINES : -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE MATLABMEX : -DMATLAB_MEX_FILE MACOSX_DEPLOYMENT_TARGET : 10.9 CFLAGS : -fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk INCLUDE : -I"/Applications/MATLAB_R2017a.app/extern/include" -I"/Applications/MATLAB_R2017a.app/simulink/include" COPTIMFLAGS : -O2 -fwrapv -DNDEBUG CDEBUGFLAGS : -g LD : /usr/bin/xcrun -sdk macosx10.12 clang LDXX : /usr/bin/xcrun -sdk macosx10.12 clang++ LDFLAGS : -Wl,-twolevel_namespace -undefined error -arch x86_64 -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -bundle -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" LDBUNDLE : -bundle FUNCTIONMAP : "/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" VERSIONMAP : "/Applications/MATLAB_R2017a.app/extern/lib/maci64/c_exportsmexfileversion.map" LINKEXPORT : -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" LINKEXPORTVER : -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/c_exportsmexfileversion.map" LINKLIBS : -L"/Applications/MATLAB_R2017a.app/bin/maci64" -lmx -lmex -lmat -lc++ LDOPTIMFLAGS : -O LDDEBUGFLAGS : -g OBJEXT : .o LDEXT : .mexmaci64 SETENV : CC="/usr/bin/xcrun -sdk macosx10.12 clang" CXX="/usr/bin/xcrun -sdk macosx10.12 clang++" CFLAGS="-fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE" CXXFLAGS="-fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -fobjc-arc -std=c++11 -stdlib=libc++ -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE" COPTIMFLAGS="-O2 -fwrapv -DNDEBUG" CXXOPTIMFLAGS="-O2 -fwrapv -DNDEBUG" CDEBUGFLAGS="-g" CXXDEBUGFLAGS="-g" LD="/usr/bin/xcrun -sdk macosx10.12 clang" LDXX="/usr/bin/xcrun -sdk macosx10.12 clang++" LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch x86_64 -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -bundle -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" -L"/Applications/MATLAB_R2017a.app/bin/maci64" -lmx -lmex -lmat -lc++ -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map"" LDDEBUGFLAGS="-g" DEVELOPER_DIR_CHECK : XCODE_DIR : /Applications/Xcode.app/Contents/Developer XCRUN_DIR : /usr/bin XCODE_AGREED_VERSION : 8.0 ISYSROOT : /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk SDKVER : 10.12 MATLABROOT : /Applications/MATLAB_R2017a.app ARCH : maci64 SRC : /Users/Z/Documents/MATLAB/mtex-4.5.0/c/mex/buffer.c;/Applications/MATLAB_R2017a.app/extern/version/c_mexapi_version.c OBJ : /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o;/var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o OBJS : /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o SRCROOT : /Users/Z/Documents/MATLAB/mtex-4.5.0/c/mex/buffer DEF : /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.def EXP : buffer.exp LIB : buffer.lib EXE : buffer.mexmaci64 ILK : buffer.ilk MANIFEST : buffer.mexmaci64.manifest TEMPNAME : buffer EXEDIR : EXENAME : buffer OPTIM : -O2 -fwrapv -DNDEBUG LINKOPTIM : -O CMDLINE100_0 : /usr/bin/xcrun -sdk macosx10.12 clang -c -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE -I"/Applications/MATLAB_R2017a.app/extern/include" -I"/Applications/MATLAB_R2017a.app/simulink/include" -fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -O2 -fwrapv -DNDEBUG /Users/Z/Documents/MATLAB/mtex-4.5.0/c/mex/buffer.c -o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o CMDLINE100_1 : /usr/bin/xcrun -sdk macosx10.12 clang -c -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE -I"/Applications/MATLAB_R2017a.app/extern/include" -I"/Applications/MATLAB_R2017a.app/simulink/include" -fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -O2 -fwrapv -DNDEBUG /Applications/MATLAB_R2017a.app/extern/version/c_mexapi_version.c -o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o
Building with 'Xcode with Clang'. /usr/bin/xcrun -sdk macosx10.12 clang -c -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE -I"/Applications/MATLAB_R2017a.app/extern/include" -I"/Applications/MATLAB_R2017a.app/simulink/include" -fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -O2 -fwrapv -DNDEBUG /Users/Z/Documents/MATLAB/mtex-4.5.0/c/mex/buffer.c -o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o /usr/bin/xcrun -sdk macosx10.12 clang -c -DTARGET_API_VERSION=700 -DUSE_MEX_CMD -DMATLAB_MEX_FILE -I"/Applications/MATLAB_R2017a.app/extern/include" -I"/Applications/MATLAB_R2017a.app/simulink/include" -fno-common -arch x86_64 -mmacosx-version-min=10.9 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -O2 -fwrapv -DNDEBUG /Applications/MATLAB_R2017a.app/extern/version/c_mexapi_version.c -o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o /usr/bin/xcrun -sdk macosx10.12 clang -Wl,-twolevel_namespace -undefined error -arch x86_64 -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -bundle -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/buffer.o /var/folders/xj/n8587c350kl19jsr684xftj00000gn/T/mex_158514494281908_90382/c_mexapi_version.o -O -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/c_exportsmexfileversion.map" -L"/Applications/MATLAB_R2017a.app/bin/maci64" -lmx -lmex -lmat -lc++ -o buffer.mexmaci64 Error using mex Undefined symbols for architecture x86_64: "_mexFunction", referenced from: -exported_symbol[s_list] command line option ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) “
I don’t really know what to make of the error or the verbose-mode feedback. I have the same problem when I try with different versions of mtex package, too (using 2017A)… but I have no problem using 2015A to install or uninstall packages. At this very moment, I am currently trying to reinstall Xcode and the command line tools in case something changed that is inhibiting progress. However, it seems weird that some of the “.C” files compile fine, and these 4 have a problem and yield the same error.
Any more thoughts/suggestions on the topic are greatly appreciated.
Thanks, Zach
On Mar 28, 2017, at 1:43 PM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Hi Zach, I think I know what might be happening. startup_mtex calls check_installation which has a function check_mex which itself calls fast_check_mex. This one tests whether mex-files are working/installed using dot_outerwhich itself uses SO3Grid_dist_region which is a mex files and this one hangs indefinitely without coming back to tell anybody what is happening, hence it will never finish the test to tell you that we should try to recompile the mex files. To fix this for it worked to re-compile the mex files. Run within c/mex mex_install and re-run startup_mtex. For me this worked. For me this worked on osx10.95 and Matlab 2017a. Seems to be an Apple only issue, no problems elsewhere. Does that work? Cheers, Rüdiger
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-289866000, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU8Hr1Ocg3OuwW8eHpZm3kel6IGRBks5rqVS1gaJpZM4MdLzj.
Hi Zach,
certainly what I forgot is, that you might need to start mtex, at least initialize the path etc. somehow, otherwise mex_install
will be missing some functions. You could have done so by commenting check_mex (line 19 in check_installation.m which resides in tools/misc_tools). But anyhow, did you try with your brandnew mex-files? I think that could be fine since if you look at the Makefile, only those 7 should be compiled - and those are the ones I get as well.
Hey,
I did try startup_mtex again after compiling those. Same thing happened with the stall and no success. I am not exactly sure what you mean about initializing the path... but what I did try was "adding" the folders and sub folders from the mtex directory, so that they were in the Matlab path. That's probably not what you mean. I am currently reinstalling some XCode tools and updating OSX in hopes it fixes the issue. If this doesn't work, I will try again with commenting the line you mention. Any other details you can think of to try?
Thanks again for all your suggestions!
Cheers, Zach
On Mar 28, 2017, at 3:38 PM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Hi Zach, certainly what I forgot is, that you might need to start mtex, at least initialize the path etc. somehow, otherwise mex_install will be missing some functions. You could have done so by commenting check_mex (line 19 in check_installation.m which resides in tools/misc_tools). But anyhow, did you try with your brandnew mex-files? I think that could be fine since if you look at the Makefile, only those 7 should be compiled - and those are the ones I get as well.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-289897100, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU96imqXZXLAVUzk65tw_PAWC0QXYks5rqW_UgaJpZM4MdLzj.
Well, I meant that for example newer_version
is also a function located in tools/misc_tolls, so that mex_install
could somehow find those. If you like, you can try those mex-files in the attachment, just copy them into c/mex/maci64 and see if that works.
Edit: and actually, if the maci64 directory is empty, mtex should also try to compile the files during check_installation.
Ug. No change.
Thanks for all the helpful suggestions, Rüdiger.
I tried reinstalling Xcode and Command Line tools (just to be sure), updated OS X, tried with the MEX files you linked, and also tried again with the ones I was able to compile. Never gets anywhere. 2017A doesn’t work with any available mtex downloads (on my computer). If I try in 2015A (any of the downloads), mtex installs and starts up in a couple seconds. So that seems (to me) to suggest the issue lies with 2017A compatibility. We have 2016A on a different MAC computer at school and it also installs fine there. I am likely incorrect, but I am convinced the issue is with 2017A Matlab for OS X… something must be different for which mtex installation is not accounting, such that it fails on the same computer where 2015A has no trouble.
Thanks again. I can’t waste more time trying to get it installed. Its a shame because I need to use toolboxes to which I have access for 2017A only, but I can’t even open the data I generate with 2015A (using mtex). Anywhooo… I look forward to any other ideas, but for now, I am not sure what else to try.
Cheers, Zach
On Mar 28, 2017, at 4:14 PM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Well, I meant that for example newer_version is also a function located in tools/misc_tolls, so that mex_install could somehow find those. If you like, you can try those mex-files in the attachment, just copy them into c/mex/maci64 and see if that works.
maci64.ziphttps://github.com/mtex-toolbox/mtex/files/877076/maci64.zip
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-289906999, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU6BYDD4q6y9fZak1gUDyDoAue8zNks5rqXhGgaJpZM4MdLzj.
Good morning Zach,
to narrow it down,
a) did you try to comment out check_mex
so you can be sure that it really is the mex-files?
b) do the files you compiled yourself work fine with another Matlab version (assuming you placed them at the right spot)?
c) Did you try it with an empty maci64 directory?
So you are using macos10.12? That's as far as I can see the only difference I can spot since Matlab 2017a on osx works ok for me, besides being a little slow, but there might also be a chance that my mex-files won't work for you.
Cheers,
Rüdiger
Good Morning, Rüdiger,
Yesterday I tried after commenting out check_mtex, and I had no luck.
Just now, I tried that again, and startup_mtex completed successfully! Not sure what I did different. But now I am able to load data and plot! I suppose that means that it is the mix-files (?). Regardless... I can use it now, and I am happy.
Thank you very much!!
cheers, Z
On Mar 29, 2017, at 3:04 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Good morning Zach, to narrow it down, a) did you try to comment out check_mex so you can be sure that it really is the mex-files? b) do the files you compiled yourself work fine with another Matlab version (assuming you placed them at the right spot)? c) Did you try it with an empty maci64 directory? So you are using macos10.12? That's as far as I can see the only difference I can spot since Matlab 2017a on osx works ok for me, besides being a little slow, but there might also be a chance that my mex-files won't work for you. Cheers, Rüdiger
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290014558, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU4zb8Ob-fKcSKDEIjMgJf-If0Xjpks5rqhB1gaJpZM4MdLzj.
Hi Zach,
yes, I actually meant commenting check_mex
not check_mtex
to start mtex so you should be able to run the build function mex_install
from within the c/mex.
Anyhow, what if you'd run a function that will require any of the mex functionality? Or do these work as well?
If so, simply emptying the maci64 directory before startup_mtex to trigger compilation of the mex-files would be a workaround if somebody else encounters this problem.
Cheers,
Rüdiger
Hi.
Yes, I mis-typed. I commented out "check_mex".
Can you give me an example of something to try that will sufficiently test the mex functionality?
Thanks, Zach
On Mar 29, 2017, at 9:45 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Hi Zach, yes, I actually meant commenting check_mex not check_mtex to start mtex so you should be able to run the build function mex_install from within the c/mex. Anyhow, what if you'd run a function that will require any of the mex functionality? Or do these work as well? If so, simply emptying the maci64 directory before startup_mtex to trigger compilation of the mex-files would be a workaround if somebody else encounters this problem. Cheers, Rüdiger
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290113081, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU3Eas55vVEU1_dKrRMJx7FlWTsUlks5rqm6TgaJpZM4MdLzj.
That's from check_installation
:
S3G = equispacedSO3Grid(crystalSymmetry,specimenSymmetry,'points',100);
dot_outer(S3G,idquaternion,'epsilon',pi/4);
Hmmm… that fails with the following error:
Undefined function or variable 'SO3Grid_dist_region'.
Error in SO3Grid/dot_outer (line 69) dist = SO3Grid_dist_region(yalpha,ybeta,ygamma, …
On Mar 29, 2017, at 10:08 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
That's from check_installation:
S3G = equispacedSO3Grid(crystalSymmetry,specimenSymmetry,'points',100); dot_outer(S3G,idquaternion,'epsilon',pi/4);
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290120292, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU82tvWQn9nz3mZlEOe9UbBbcZr2Zks5rqnPlgaJpZM4MdLzj.
So what's in your c/mex/maci64 directory?
Nevermind… if I run it inside the mex folder, it completes.
On Mar 29, 2017, at 10:08 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
That's from check_installation:
S3G = equispacedSO3Grid(crystalSymmetry,specimenSymmetry,'points',100); dot_outer(S3G,idquaternion,'epsilon',pi/4);
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290120292, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU82tvWQn9nz3mZlEOe9UbBbcZr2Zks5rqnPlgaJpZM4MdLzj.
Ok, so to resume: Now you can run startup_mtex
without having check_mex
commented out and everything works fine?
If I run the test inside the mex folder, it completes. If I run it inside the maci64 directory, it does not complete. Matlab hangs and can’t be interrupted, so I need to force quit.
On Mar 29, 2017, at 10:13 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
So what's in your c/mex/maci64 directory?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290121939, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQUxC1874-XRksSolA3BMSIBesbbc9ks5rqnUagaJpZM4MdLzj.
Ok,so which files are in you maci64 folder and are there any compiled ones in the mex folder itself?
Sorry for delay, had a meeting…
Here’s what I did:
I removed all the files from maci64. Uncommented check_mex. I then ran startup_mtex The script looks for them and doesn’t find the mex-files, so then compiles them and completes successfully.
Here’s the messages:
startup_mtex initialize MTEX 4.5.0 ....Warning: missing mex-file S1Grid_find.mexmaci64 In check_installation>fast_check_mex (line 190) In check_installation>check_mex (line 113) In check_installation (line 19) In startup_mtex (line 74)
Checking mex files failed!
Trying now to recompile mex files. ... compile S1Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S1Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S2Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S2Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_dist_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully.
Afterward, the maci64 folder is repopulated. Also, the test for the mex files you mentioned completes/works. So it seems that a solution is to delete all the mex files in the maci64 folder and run the startup_mtex. That is fantastic to know! It is still odd to me that none of this is necessary with the identical mtex files in my 2015a Matlab installation. But all I need is it working, so this is great.
Thanks again! Zach
On Mar 29, 2017, at 10:16 AM, kilir notifications@github.com<mailto:notifications@github.com> wrote:
Ok, so to resume: Now you can run startup_mtex without having check_mex commented out and everything works fine?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-290122858, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU7MRTMKkJt3IjMnucww9hO6d9kEvks5rqnXIgaJpZM4MdLzj.
Great. Maybe add workaround/solution or something to the title in case someone has the same problem. Cheers, Rüdiger
It seem there where some changes to mex-files, however in that case seems to be only triggered for ApplesOs. https://mathworks.com/help/matlab/release-notes.html https://mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html https://mathworks.com/help/matlab/matlab_external/what-if-i-do-not-upgrade.html
Hello Zach, Any chance you could share the files you compiled for the c/mex/maci64 directory? I'm having the exact same issue as you trying to run mtex in Matlab 2017a, but xcode is giving me an error and I'm being unable to compile my own files.
e.g., Compiling /Users/..../c/mex/SO3Grid_dist_region.c failed!
I tried running mtex_startup with an empty maci64 folder, and also using the files that Rüdiger shared but neither did it for me (I followed all the tricks suggested in this thread, for that matter, and still couldn't get it to work). cheers, Mauricio
Hi Mauricio,
Here are two sets of MEX files residing in my mtex folder. The ones in the maci64.zip are the ones from my maci64 folder. The ones in the mex.zip are files with the same name that aer in my mex folder (one level above the maci64 folder). I hope these are some help. Let me know if there is anything else I can try/share or help with.
Best, Zach
Hi Zach,
Thanks for the files! I removed the original .mexmaci64 filed from the c/mex/maci64 folder, commented out check_mex, ran startup_mtex, and then placed the files you sent in the empty maci64 folder.
I then tested it running the command Rüdiger suggested:
S3G = equispacedSO3Grid(crystalSymmetry,specimenSymmetry,'points',100); dot_outer(S3G,idquaternion,'epsilon',pi/4);
I did it from the main mtex directory and it worked fine.
This is a very useful thread! and thanks for the help sending out those files.
best, Mauricio
Hi Zach,
I have one more question for you. Have you tested any of the functionalities of the libraries that reside under the c/bin/maci64 folder with your 2017a installation? I'm having issues calculating ODF's, and it is the c/bin/maci64/libnfft3.1.dylib that comes up in the log as a possible problem.
If you load the tutorial data: mtexdata forsterite And try to calculate an ODF: odf = calcODF(ebsd('fo').orientations)
Does it complete successfully or do you get an error? (error that I get is pasted below). If it runs well, would you mind sharing the files under your c/bin/maci64 folder as well? (the ones under the mtex folder seem to be working well thus far).
Thanks, Mauricio
Error using call_extern (line 160) Error running external program: odf2fc show logfile
Error in unimodalComponent/calcFourier>gcA2fourier (line 68) f = call_extern('odf2fc','EXTERN',g,c,A);
Error in unimodalComponent/calcFourier (line 29) f_hat = gcA2fourier(abg,c,A);
Error in ODF/calcFourier (line 32) hat = calcFourier(odf.components{i},L,varargin{:});
Error in ODF/FourierODF (line 8) f_hat = calcFourier(odf,varargin{:});
Error in orientation/calcFourierODF (line 54) odf = FourierODF(odf,get_option(varargin,{'L','bandwidth','fourier'},L,'double'));
Error in orientation/calcODF (line 64) odf = calcFourierODF(ori,varargin{:},'kernel',psi);
Error in test_Kov7 (line 76) odf = calcODF(ebsd('Zr02 monoclinic').orientations,'halfwidth',10*degree)
And this is the logfile: dyld: Library not loaded: /opt/local/lib/libfftw3.3.dylib Referenced from: /Users/Ibanez-Mejia/Documents/MATLAB/mtex-4.5.0/c/bin/maci64/libnfft3.1.dylib Reason: image not found
Hi Mauricio
The libraries work fine for me (no problems /errors calculating ODFs or plotting contours of axial data). Have you also checked to disable SIP on the Mac? It has caused some problems, and I think the errors people get are something similar about error running external program. Let me know if there is any way I can help.
Best, Zach
On Apr 23, 2017, at 8:55 AM, ibanezmejia notifications@github.com<mailto:notifications@github.com> wrote:
Hi Zach,
I have one more question for you. Have you tested any of the functionalities of the libraries that reside under the c/bin/maci64 folder with your 2017a installation? I'm having issues calculating ODF's, and it is the c/bin/maci64/libnfft3.1.dylib that comes up in the log as a possible problem.
If you load the tutorial data: mtexdata forsterite And try to calculate an ODF: odf = calcODF(ebsd('fo').orientations)
Does it complete successfully or do you get an error? (error that I get is pasted below). If it runs well, would you mind sharing the files under your c/bin/maci64 folder as well? (the ones under the mtex folder seem to be working well thus far).
Thanks, Mauricio
Error using call_extern (line 160) Error running external program: odf2fc show logfile
Error in unimodalComponent/calcFourier>gcA2fourier (line 68) f = call_extern('odf2fc','EXTERN',g,c,A);
Error in unimodalComponent/calcFourier (line 29) f_hat = gcA2fourier(abg,c,A);
Error in ODF/calcFourier (line 32) hat = calcFourier(odf.components{i},L,varargin{:});
Error in ODF/FourierODF (line 8) f_hat = calcFourier(odf,varargin{:});
Error in orientation/calcFourierODF (line 54) odf = FourierODF(odf,get_option(varargin,{'L','bandwidth','fourier'},L,'double'));
Error in orientation/calcODF (line 64) odf = calcFourierODF(ori,varargin{:},'kernel',psi);
Error in test_Kov7 (line 76) odf = calcODF(ebsd('Zr02 monoclinic').orientations,'halfwidth',10*degree)
And this is the logfile: dyld: Library not loaded: /opt/local/lib/libfftw3.3.dylib Referenced from: /Users/Ibanez-Mejia/Documents/MATLAB/mtex-4.5.0/c/bin/maci64/libnfft3.1.dylib Reason: image not found
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-296444986, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU3wV3o_hUre2eV-Idzs1C2563tOEks5ry1hVgaJpZM4MdLzj.
Hi guys. So.... having similar issues and trying very hard to follow the instructions in this thread. Basics - am trying to compile MTEX on MatlabR2017a on OSX10.12.6 I think it works, but then I can't calculate ODFs, so it clearly hasn:t worked.
Things I have tried:
mex_install ... compile S1Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S1Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S2Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile S2Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_dist_region.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_find.c Building with 'Xcode with Clang'. MEX completed successfully. ... compile SO3Grid_find_region.c Building with 'Xcode with Clang'. MEX completed successfully.
Then run startup_mtex from the top level of my Mtex folder, yielding
startup_mtex initialize MTEX 4.4.0 ..../bin/bash: line 1: 90581 Abort trap: 6 /Applications/mtex-4.4.0/c/bin/maci64/odf2pf /private/tmp/odf2pf15470.txt 2>> /private/tmp/output_VirginiasMacBookAirlocal_vt.log /Applications/mtex-4.4.0/c/bin/maci64/odf2pf /private/tmp/odf2pf15470.txt 2>> /private/tmp/output_VirginiasMacBookAirlocal_vt.log: Aborted
MTEX binary check failed!
The original error message was: Error using call_extern (line 160) Error running external program: odf2pf show logfile
Check the following options:
/bin/bash: line 1: 90584 Abort trap: 6 /Applications/mtex-4.4.0/c/bin/maci64/odf2fc /private/tmp/odf2fc15484.txt 2>> /private/tmp/output_VirginiasMacBookAirlocal_vt.log /Applications/mtex-4.4.0/c/bin/maci64/odf2fc /private/tmp/odf2fc15484.txt 2>> /private/tmp/output_VirginiasMacBookAirlocal_vt.log: Aborted done!
MTEX 4.4.0 (show documentation) Import pole figure data Import EBSD data Import ODF data
Uninstall MTEX
ANY SUGGESTIONS ON HOW TO PROCEED????
V
Solved!
I disabled SIP. Then I deleted the thingameejigs from maci64, simply ran startup_mtex from top level, it compiled the thingameejigs and installed MTEX happily, and then it calculated my ODFs :).
Can I safely re-enable SIP now? I am going to try since I feel it was initially enable for some reason, even if I don:t know what that reason is.
So... now I have to go back to the hard part of deciding if the resulting pole figs are scientifically significant.
Darn. Not resolved. Rebooted, re-enabled SIP, and on return to Matlab encountered a bunch of errors on MTEX startup, which I didn:t copy. Rebooted again, disabled SIP, and on return to Matlab startup incl. attempt to start MTEX yields:
java.lang.reflect.InvocationTargetException
at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:572)
at sun.lwawt.macosx.CInputMethod.firstRectForCharacterRange(CInputMethod.java:713)
Caused by: java.lang.NullPointerException
at sun.lwawt.macosx.CInputMethod$6.run(CInputMethod.java:734)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:302)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:738)
at java.awt.EventQueue.access$300(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:699)
at java.awt.EventQueue$3.run(EventQueue.java:697)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:713)
at java.awt.EventQueue$4.run(EventQueue.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:710)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Then, my MTEX script does actually run through wuite far... incl. calculating an ODF and generating some pole figs, but eventually hangs telling me this:
Error using cellfun
Input #2 expected to be a cell array, was char instead.
Error in calcTightInset (line 26)
s = get(txt,'string'); ind = cellfun(@isempty,s);
Error in mtexFigure/drawNow (line 17)
[mtexFig.tightInset,mtexFig.figTightInset] = calcTightInset(mtexFig);
Error in ODF/plotPDF (line 73)
mtexFig.drawNow('figSize',getMTEXpref('figSize'),varargin{:});
Error in MTEX05030105_script (line 115)
plotPDF(odf_Quartz,PFs_Quartz_hkil,'contourf','antipodal','3d');_
It seems this error is associated with this bit of the script
figure
setMTEXpref('FontSize',25)
plotPDF(odf_Quartz,PFs_Quartz_hkil,'contourf','antipodal','3d');
mtexColorbar
annotate([xvector,yvector,-zvector],'label',{'X','Y','Z'},'backgroundcolor','w','MarkerSize',15,'FontSize',20)
drawNow(gcm,'figSize','large')
So... what does this mean? Just don't try to do the 3D plots? Guess so
May I ask which Matlab version you are using?
Maybe you should not start with the 3d option if your Matlab is a bit unstable :)
Ralf.
Dr. Virginia Toy Senior Lecturer Department of Geology University of Otago PO Box 56 (mail) or 360 Leith St (courier) Dunedin 9054 NEW ZEALAND Ph: +64 21 127 1012 Email: virginia.toy@otago.ac.nzmailto:virginia.toy@otago.ac.nz Skype: aramoanav
On Aug 30, 2017, at 3:50 PM, Ralf Hielscher notifications@github.com<mailto:notifications@github.com> wrote:
May I ask which Matlab version you are using?
Maybe you should not start with the 3d option if your Matlab is a bit unstable :)
Ralf.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/238#issuecomment-325899132, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ad-msxMDF4RYGR07LSUA1hnXShCNwXfUks5sdQZCgaJpZM4MdLzj.
I hope with MTEX 5.0 this issue is resolved.
I just installed Matlab 2017a today. When I run startup_mtex.m, my system hangs indefinitely and never completes. This is the case for any versions I try downloading from the download site. My other version of Matlab is 2015b, and all the installs work on it. Is 2017 not (yet) supported?
Thanks, Zach