search

mtex-toolbox / mtex

MTEX is a free Matlab toolbox for quantitative texture analysis. Homepage:
http://mtex-toolbox.github.io/
GNU General Public License v2.0
292 stars 186 forks source link

installation errors #237

Closed enadin closed 6 years ago

enadin commented 7 years ago

First-time mtex user here. Mac 10.12.3, Matlab 9.1.0.441655 (R2016b). Below is what I see in the Matlab command window when I run the startup script. Can someone please suggest how to proceed?

startup_mtex initialize MTEX 4.5.beta.3 ..../bin/bash: line 1: 33358 Abort trap: 6 /Users/ENadin/Documents/Research/Quartz_CPO/mtex-4.5.beta.3/c/bin/maci64/odf2pf /private/tmp/odf2pf8541.txt 2>> /private/tmp/output_ElisabethsMacBookProlocal_ENadin.log /Users/ENadin/Documents/Research/Quartz_CPO/mtex-4.5.beta.3/c/bin/maci64/odf2pf /private/tmp/odf2pf8541.txt 2>> /private/tmp/output_ElisabethsMacBookProlocal_ENadin.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: 33362 Abort trap: 6 /Users/ENadin/Documents/Research/Quartz_CPO/mtex-4.5.beta.3/c/bin/maci64/odf2fc /private/tmp/odf2fc8700.txt 2>> /private/tmp/output_ElisabethsMacBookProlocal_ENadin.log /Users/ENadin/Documents/Research/Quartz_CPO/mtex-4.5.beta.3/c/bin/maci64/odf2fc /private/tmp/odf2fc8700.txt 2>> /private/tmp/output_ElisabethsMacBookProlocal_ENadin.log: Aborted done!

MTEX 4.5.beta.3 (show documentation) Import pole figure data Import EBSD data Import ODF data

Uninstall MTEX

zmichels commented 7 years ago

Try installing using one of the versions on the download page (rather than direct from the GIT repository). The download versions have the binaries already built. Perhaps you have already tried this. If not, give it a shot. Here's the link to the main mtex download page: https://mtex-toolbox.github.io/download.html

enadin commented 7 years ago

Hi zmichels, thanks for your answer. I had already seen this suggestion in a previous thread, and it didn't work. I suspect that it's because I'm using Matlab 2016b, which is not shown as tested yet. Someone else made a similar complaint today and they are using 2017. We also tried 3 different version of mtex, with no go.

ralfHielscher commented 7 years ago

Hi enadin,

this has nothing to do with the Matlab version. I do run MTEX on Matlab 2017a. This is probably a Mac specific problem. Have you clicked the link "show logfile"? Could you please send the error message contained in the logfile?

Ralf.

enadin commented 7 years ago

Hi Ralf, thanks for being in touch. here is the error message in the logfile:

dyld: Library not loaded: /opt/local/lib/libfftw3.3.dylib Referenced from: /Applications/Matlab/mtex-4.5.beta.3/c/bin/maci64/libnfft3.1.dylib Reason: image not found dyld: Library not loaded: /opt/local/lib/libfftw3.3.dylib Referenced from: /Applications/Matlab/mtex-4.5.beta.3/c/bin/maci64/libnfft3.1.dylib Reason: image not found

I don't know if this helps at all, but another issue seems to be this: when i click on "compile the binaries yourself" there is a list of prerequisites, none of which I think I have (gcc, make utility, etc)

ralfHielscher commented 7 years ago

You may have a look at this threat https://github.com/mtex-toolbox/mtex/issues/107#issuecomment-264555557

there they propose:

We made copies of the two .dylib files from the (mtex)/c/bin/maci64/ to /opt/local/lib/

Ralf.

enadin commented 7 years ago

hi again Ralf, I followed the thread but the suggestion is a non-starter for me -- it requires root permission, which I do not have for my Mac. I noticed the note from David Mainprice on that thread-- he said he's running 2016a with no problem so the issue was resolved by Mathworks. I'm running 2016b, so I imagine it would be the same. any other suggestions?

kilir commented 7 years ago

Hi Elisabeth, I thought booting into recovery mode to disable SIP (did you try that?) should go without being admin. However, if this did not work, and if you are not administrator nor your user is at least in the sudoers file with sufficient rules and csrutil status tells you that SIP is enabled, you probably have to talk to the owners of the computer whether they could either disable SIP or sudo cp /Users/ENadin/Documents/Research/Quartz_CPO/mtex-4.5.beta.3/c/bin/maci64/*.dylib /opt/local/lib/ for you and check if that works. Compiler, make, etc. comes as so called "command line tools" with xcode (besidessome GB of other things), however I can't confirm that it is required since I don't have a machine without it. Cheers, Rüdiger

jamiek commented 7 years ago

I just encountered this issue. The problem is that one of the libraries is improperly linked. As noted above and in issue #107 this can be fixed by copying the files to the location referenced.

The proper way to address this it to fix the link so that the proper file location is referenced. This can be fixed by opening a terminal and changing directory to the location of the dynamic library that is not properly linked, for example (mtex-4.5.0/c/bin/maci64) then use install_name_tool to fix the link:

install_name_tool -change /opt/local/lib/libfftw3.3.dylib @loader_path/libfftw3.3.dylib libnfft3.1.dylib

you can check to ensure that the link is updated using the following command otool -L libfftw3.1.dylib and ensuring that the link to libfftw3.3.dylib starts with @loader_path

MTEX should run after this.

The developers should be able to apply this fix to their local copy and distribute it with future releases. I'm happy to push a .dylib with proper linking if that helps. That said, whoever is making the mac builds likely needs to update their build scripts to keep this from happening in the future.

ralfHielscher commented 7 years ago

Hi Jamiek,

this would definitely help. I do not own a Mac - therefore my possibilities are a bit limited. The solution you propose can be applied to the distributed binaries and would be independent from the exact folder of installation?

Thank you very much,

Ralf.

zmichels commented 7 years ago

This did not solve my install issue with 2017A. Thank you for the info, however.

After following these instructions, I use the command to check as suggested, and I get the following confirmation: MacBook-Air-2:maci64 Z$ otool -L libnfft3.1.dylib libnfft3.1.dylib: /Users/florian/data/src/unix/mtex/nfft-3.2.2/nfft-bin/lib/libnfft3.1.dylib (compatibility version 2.0.0, current version 2.0.0) @loader_path/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

I think that means it worked. But when I try to install on 2017A, it still hangs and never completes (it also never throws an error). Again, the packages all install fine on my machine with releases prior to 2017A. That is, I have a 2015A, and all mtex packages install successfully when I run them in 2015A. All mtex packages freeze and never complete when I try to install them using 2017A. This problem persists even after following the instructions for the issue with improperly linked libraries.

I will continue to use 2015A for mtex, but I look forward to any suggestions for how to get working with 2017A because my institution’s site license for 2017A includes many more toolboxes that I plan to use regularly.

Thanks and cheers, Zach

On Mar 27, 2017, at 5:21 PM, Jamie Kimberley notifications@github.com<mailto:notifications@github.com> wrote:

I just encountered this issue. The problem is that one of the libraries is improperly linked. As noted above and in issue #107https://github.com/mtex-toolbox/mtex/issues/107 this can be fixed by copying the files to the location referenced.

The proper way to address this it to fix the link so that the proper file location is referenced. This can be fixed by opening a terminal and changing directory to the location of the dynamic library that is not properly linked, for example (mtex-4.5.0/c/bin/maci64) then use install_name_tool to fix the link:

install_name_tool -change /opt/local/lib/libfftw3.3.dylib @loader_path/libfftw3.3.dylib libnfft3.1.dylib

you can check to ensure that the link is updated using the following command otool -L libfftw3.1.dylib and ensuring that the link to libfftw3.3.dylib starts with @loader_path

MTEX should run after this.

The developers should be able to apply this fix to their local copy and distribute it with future releases. I'm happy to push a .dylib with proper linking if that helps. That said, whoever is making the mac builds likely needs to update their build scripts to keep this from happening in the future.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/mtex-toolbox/mtex/issues/237#issuecomment-289603621, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXQU2gwDB0cKeGPe43RymLatjp6JXd5ks5rqDZYgaJpZM4McLGG.

ralfHielscher commented 6 years ago

I hope with MTEX 5.0 this issue is resolved.