Back to the main page.
Bug 1258 - solid_angle (and potentially other mex-files) have ill-defined dependencies, especially on Windows
| Status | CLOSED FIXED |
| Reported | 2012-01-15 21:34:00 +0100 |
| Modified | 2012-08-23 10:35:11 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Eelke Spaak |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 13841385 |
| See also: |
Vadim - 2012-01-15 21:34:37 +0100
Hi, Environment specification: Windows 7, 64 bit Matlab 2009B, 64 bit Tutorial code from: http://fieldtrip.fcdonders.nl/tutorial/beamformer At the bottom of the Email is the code (combined from tutorial code boxes). In fieldtrip-20120106 for the line: [grid] = ft_prepare_leadfield(cfg); I get the error: ??? Invalid MEX-file 'D:\MEG\toolboxes\fieldtrip-20120106\private\solid_angle.mexw64': The specified module could not be found. Interestingly, the file does exist at this location (probably damaged). With version fieldtrip-20111007 everything runs fine. Thank you, Vadim load 'dataFIC.mat'; cfg = []; cfg.toilim = [-0.5 0]; dataPre = ft_redefinetrial(cfg, dataFIC); cfg.toilim = [0.8 1.3]; dataPost = ft_redefinetrial(cfg, dataFIC); cfg = []; cfg.method = 'mtmfft'; cfg.output = 'powandcsd'; cfg.tapsmofrq = 4; cfg.foilim = [18 18]; freqPre = ft_freqanalysis(cfg, dataPre); cfg = []; cfg.method = 'mtmfft'; cfg.output = 'powandcsd'; cfg.tapsmofrq = 4; cfg.foilim = [18 18]; freqPost = ft_freqanalysis(cfg, dataPost); load 'segmentedmri.mat'; cfg = []; vol = ft_prepare_singleshell(cfg, segmentedmri); cfg = []; cfg.grad = freqPre.grad; cfg.vol = vol; cfg.reducerank = 2; cfg.channel = {'MEG','-MLP31', '-MLO12'}; cfg.grid.resolution = 1; % use a 3-D grid with a 1 cm resolution [grid] = ft_prepare_leadfield(cfg);
Eelke Spaak - 2012-02-29 14:13:25 +0100
*** Bug 1345 has been marked as a duplicate of this bug. ***
Eelke Spaak - 2012-02-29 14:16:27 +0100
Hi Vadim and Ana, I have tried to reproduce the bug you report, but everything seems to work fine on my end. It might be that something changed inthe handling of the mex-files recently, could you check whether you still get the bug in the latest version of Fieldtrip? The simplest test is probably just to execute something like: >> cd H:/common/matlab/fieldtrip/private >> w=solid_angle([1 2 3],[1 2 3],[1 2 3]) w = 0 >> which solid_angle H:\common\matlab\fieldtrip\private\solid_angle.mexw64 % Private to fieldtrip Please also include the 'which' statement, the output from that might be relevant to the issue.
Vadim - 2012-03-07 10:50:25 +0100
(In reply to comment #2) No it seems working for me as well. So, you can close the bug, I think. Thanks
- 2012-03-08 12:19:02 +0100
Hi, I am sorry but it didn't work for me.. I get the same error message: Invalid MEX-file 'C:\Program Files\fieldtrip-20120304\private\solid_angle.mexw64': The specified module could not be found. Error in bounding_mesh (line 71) solang = solid_angle(tmp, tri); Error in ft_prepare_sourcemodel (line 693) tmp = bounding_mesh(grid.pos, pnt, tri); Error in ft_prepare_leadfield (line 164) grid = ft_prepare_sourcemodel(tmpcfg); I also try what you told me: w=solid_angle([1 2 3],[1 2 3],[1 2 3]) but I got again the error message: Invalid MEX-file 'C:\Program Files\fieldtrip-20120304\private\solid_angle.mexw64': The specified module could not be found. I'm working with the fieldtrip-20120304 version. Thanks. Greetings, Ana Sofia
Eelke Spaak - 2012-03-08 12:22:47 +0100
Thank you both for the feedback. @Vadim: good to hear that it works for you :) @Ana Sofia: I will look into why you are still having trouble. It could be a specific dependency not being found by a particular Matlab version. What matlab version are you using?
- 2012-03-08 14:52:58 +0100
Hi, I have the 2011b Matlab version. Thanks!
Vadim - 2012-03-08 20:39:23 +0100
(In reply to comment #6) Hi guys/girls, I think I probably have a clue. In fact, I did not download the newest build, but only tested the one that originally had not work for me. Now, all of a sudden, it started to work. Given that I do not believe it magic, something changed in my environment. What came to my mind that recently I struggled with libsvm mex file, which also refused to run. I think the reason was similar to this one. The problem was that some matlab dll was missing from Windows PATH definition (system variable environment in Control Panel). As a result the mex file was missing required dependency. This can be easily tracked by using this tool: http://www.dependencywalker.com/ My guess is that updating the path also fixed the fieldtrip issue. Here is the path I have now: C:\Program Files\MATLAB\R2009b\runtime\win64;C:\Program Files\MATLAB\R2009b\bin;C:\Program Files\MATLAB\R2009b\bin\win64 It seems that I was missing the last one. Clearly, all we are using 64-bit matlab. So, Ana, I suggest that you try to check in this direction.
Eelke Spaak - 2012-03-14 09:59:11 +0100
Ana, it could be that you are missing the Microsoft Visual C++ 2010 runtime, which (unfortunately) is required by this particular MEX-file. You can download this runtime from: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555 Could you let me know if this solves the issue for you? (Or perhaps has Vadim's suggestion already solved it?) We are trying to think of a way to remove the linkage of our mex-files to the MSVC runtime DLLs, but this proves to be quite difficult.
- 2012-03-15 10:49:22 +0100
I just had replaced the solid angle file in the fieldtrip version I have for an old version one and now its working. Thanks!
Eelke Spaak - 2012-03-21 15:42:40 +0100
*** Bug 1381 has been marked as a duplicate of this bug. ***
Robert Oostenveld - 2012-03-21 16:38:01 +0100
mex files are actually dynamically linked libraries (DLL). That applies to all platforms, also linux and OSX. The tool from dependencywalker.com can be used to look at other dynamical libraries to which the DLL is linked. Alternatively, it seems that linux strings+grep also gives the required info. The following is for windows 64 bit mex files manzana> pwd /Volumes/Data/roboos/matlab/fieldtrip/src manzana> strings *.mexw64 | grep -i dll | sort | uniq KERNEL32.dll MSVCR100.dll MSVCR80.dll MSVCR90.dll __dllonexit libmex.dll libmx.dll and for windows 32 bit mex files manzana> strings *.mexw32 | grep -i dll | sort | uniq CRTDLL.DLL KERNEL32.dll MSVCR90.dll __dllonexit kernel32.dll libgcc_s_dw2-1.dll libgcj-12.dll libmex.dll libmx.dll msvcrt.dll We have identified MSVCR80, MSVCR90 and MSVCR100 as possible problematic. These seem to result from compilation on windows using different VisualC++ compilers. See also http://support.microsoft.com/kb/326922 The table above also suggests that with libgcc_s_dw2-1.dll there is a dependency that relates to the GCC compiler, which is perhaps from MingW or Cygwin. For 32 bit windows I don't see a reason to _not use_ the lcc compiler. See also http://www.mathworks.nl/support/compilers/R2012a/win32.html For 64 bit windows LCC is not available. We should try to use the same compiler throughout. See also http://www.mathworks.nl/support/compilers/R2011b/win64.html TODO: - for win32 find out the mex files that were compiled with another compiler than LCC - for win64 find out which compilers were used and probably try to converge on a compiler that is not the oldest, but also not the latest.
Robert Oostenveld - 2012-03-21 16:48:59 +0100
(In reply to comment #11) for win32 the following mex files seem to be compiled with another compiler than LCC manzana> grep -i MSVCR90 *.mexw32 Binary file getpid.mexw32 matches Binary file nanmean.mexw32 matches Binary file nansum.mexw32 matches Binary file nanvar.mexw32 matches manzana> grep -i libgcc_s_dw2-1 *.mexw32 Binary file ft_getopt.mexw32 matches manzana> grep -i libgcj-12 *.mexw32 Binary file ft_getopt.mexw32 matches I am not sure about the CRTDLL.DLL, but it seems to be rarely used, suggesting it is also the result of an unusual mex compilation procedure. manzana> grep -i CRTDLL.DLL *.mexw32 Binary file ltrisect.mexw32 matches Binary file plinproj.mexw32 matches Binary file routlm.mexw32 matches Note that besides MSVC 2005, 2008, 2010, also Mingw , Cygwin, Borland C++ 5.5 and I believe Borland Builder 6.0 have been in use at the Donders. Now that I think of it... (supported by google) the CRTDLL.DLL seems to be the result of mex file compilation with a Borland compiler.
Eelke Spaak - 2012-03-21 16:53:13 +0100
I probably compiled ft_getopt.mex32 for the last time, using MinGW on my machine. DependencyWalker does not show any unusual dependencies for that one, though, so perhaps the strings|grep approach shows other stuff besides dependencies as well.
Robert Oostenveld - 2012-03-21 17:08:52 +0100
(In reply to comment #11) regarding win64 compilers, according to http://www.mathworks.nl/support/sysreq/previous_releases.html and http://www.mathworks.nl/support/compilers/R2012a/win64.html MSVC 2008 seems to be supported up to the latest (2012a) and going back to 2008a. With http://support.microsoft.com/kb/326922 in mind that means that we should aim for MSVCR90.DLL
Robert Oostenveld - 2012-03-21 17:14:49 +0100
(In reply to comment #14) The win64 mex files without MSVCR90 seem to be manzana> grep -L MSVCR90 *.mexw64 lmoutr.mexw64 ltrisect.mexw64 meg_leadfield1.mexw64 mxDeserialize.mexw64 mxSerialize.mexw64 nanstd.mexw64 nanvar.mexw64 plgndr.mexw64 ptriproj.mexw64 read_16bit.mexw64 read_24bit.mexw64 routlm.mexw64 solid_angle.mexw64 splint_gh.mexw64 This selection has the following DLLs manzana> strings `cat out` | grep -i dll | sort | uniq KERNEL32.dll MSVCR100.dll MSVCR80.dll __dllonexit libmex.dll libmx.dll
Yoni Levy - 2012-03-21 17:23:32 +0100
(In reply to comment #15) I am using: Windows 7 Pro, win64, Matlab 2011b. I have tried following the past suggestions (from a few days/weeks ago) raised in the thread (e.g. adding paths), but these did not solove the bug. However, I have followed the later suggestions to download the adequate compiler from: http://www.mathworks.com/support/compilers/R2011b/win64.html#matlab As indeed is indicated above, this C compiler is not availble with Matlab. After downloading the compiler, and running the "ft_prepare_leadfield", it is now functioning correctly. From my side the bug is solved. Thanks to all of you. Yoni
Robert Oostenveld - 2012-03-21 18:00:40 +0100
After personal discussion with Eelke, we have come to a resolution. I have added http://fieldtrip.fcdonders.nl/code_guidelines?&#compiling_mex_files which states Windows 32 bit You should use the LCC compiler that is included with MATLAB. Windows 64 bit The 64-bit versions of MATLAB do not come with a compiler (see for example here and here). Furthermore, a C/C++ compiler is by default not available on Windows systems, therefore you are required to install a compiler to (re)compile the mex files. You should use the Microsoft Visual C++ 2008 compiler. This compiler is available for free in the MSVC 2008 Express Edition and is supported in MATLAB2012a and older versions (going back to 2008). I will close this bug now, as we will follow it up with two new bug that specifically state bug #1384 - mex files for windows 32 should be compiled according to the guidelines bug #1385 - mex files for windows 64 should be compiled according to the guidelines