Back to the main page.
Bug 2913 - Typo in ft_getopt.c (mxErrMsgTxt) renders MEX-file invalid in R2015b
| Status | CLOSED FIXED |
| Reported | 2015-06-24 12:55:00 +0200 |
| Modified | 2016-06-14 16:14:50 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2989 |
| See also: |
Guillaume - 2015-06-24 12:55:02 +0200
There is a typo at l.49 of ft_getopt.c: mxErrMsgTxt() instead of mexErrMsgTxt(). R2015b beta considers the MEX-file as invalid: >> ft_getopt Invalid MEX-file /fieldtrip/fileio/private/ft_getopt.mexa64: undefined symbol: mxErrMsgTxt
Robert Oostenveld - 2015-06-24 13:47:38 +0200
weird that it is not a problem in pre 2015b versions. This fixes the source code, the mex files still need to be recompiled. mac011> svn commit Sending ft_getopt.c Transmitting file data . Committed revision 10478.
Robert Oostenveld - 2015-06-24 14:07:35 +0200
I recently moved th eft_compile_mex helper function to utilities, and it needed a small fix for the changed path. I recompiled ft_getopt for maci64 mac011> svn commit Adding (bin) fileio/private/sap2matlab.mexmaci64 Adding (bin) realtime/src/acquisition/siemens/src/sap2matlab.mexmaci64 Sending src/ft_getopt.mexmaci64 Sending utilities/ft_compile_mex.m Transmitting file data .... Committed revision 10480.
- 2015-09-10 19:30:42 +0200
Instead of the error 'undefined symbol: mxErrMsgTxt', I receive this error in the new 2015b release (Windows 7 & 10, 64bit): Invalid MEX-file '~\fieldtrip\utilities\ft_getopt.mexw64': The specified procedure could not be found. To test for mex compiling, I've run 'ft_compile_mex' without error.
Robert Oostenveld - 2015-09-11 08:39:16 +0200
(In reply to koreykam from comment #3) Hi Korey, The ft_compile_mex function compiles all files but does not yet put them in the right place. That means that the old mex files are still taking precedence. You should delete all existing mex files (on the basis of the file extension) and then put the newly compiled ones in a directory on your path. I.e. they dnot have to be in private, anywhere on your path is fine. Hope this helps. Now that 2015b is out, I might be able to get it from our IT department. I will ask. @Guillaume: how did you arrange to get pre-releases?
- 2015-09-11 15:23:11 +0200
That helps. My first problem was that 2015b did not recognize my prev installed compiler. Following this answer resolved it: http://www.mathworks.com/matlabcentral/answers/95039-why-does-the-sdk-7-1-installation-fail-with-an-installation-failed-message-on-my-windows-system#answer_104391
Guillaume - 2015-09-11 21:00:20 +0200
(In reply to Robert Oostenveld from comment #4) My MathWorks account is linked to the site license - I guess you need to talk to the person administrating the licenses in your institution to be granted access to beta versions. There was one issue with R2015b and @xmltree (used by @gifti): you should update the version in FieldTrip (using the dev version of SPM12, or from their respective website).
Robin - 2015-10-29 12:21:17 +0100
We are having this problem. While the C code was fixed it seems that compiled files stored in the repository have not been rebuilt. We will try to rebuild ourselves, but would it be possible to update ft_getopt.mexa64 (probably other platforms too) in the repository so a checkout will work with current Matlab? Thanks
Luca Ambrogioni - 2015-11-16 11:56:12 +0100
Hi Guys, I found the cause of the problem. It is not about the compilation but rather the C code per se. The problem is that the function "mxErrMsgTxt" is not supported in matlab2015b, we need to replace it with: "mexErrMsgIdAndTxt". Given the generality of the defective function, I suppose that this has to be done for almost all the our c codes, but for now I found the problem only in ft_getopt. (The new function takes 2 arguments instead of 1) Unfortunately it seems that there are some problems of compatibility between 2012b and 2015b. The ft_getopt mex file that I compiled for 2015b gives the following error in 2012b: "mexGetVariableWithObject"
Robin - 2015-11-16 12:11:38 +0100
Luca - the problem was a typo that only affected ft_getopt.c (mxErrMsgTxt -> mexErrMsgTxt). It was fixed in June (commit 10480). Since the problem was initially reported on a Mac, only the Mac binary was recompiled. So at the moment just the ft_getopt.mexa64 needs to be recompiled for this issue.
Robert Oostenveld - 2015-11-17 16:41:27 +0100
I recompiled the mex files on 64 bit osx and linux. ------------------------------------------------------------------------ r10898 | roboos | 2015-11-17 15:37:41 +0100 (Tue, 17 Nov 2015) | 2 lines recompiled most mex files with MATLAB R2012b on OS X 10.9, see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2913 ------------------------------------------------------------------------ r10900 | roboos | 2015-11-17 16:39:11 +0100 (Tue, 17 Nov 2015) | 2 lines recompiled mex files on matlab 2012b with gcc-4.8.3 on centos 7.1
Robert Oostenveld - 2015-11-17 18:15:29 +0100
(In reply to Robert Oostenveld from comment #10) I also recompiled on 32 and 64 bit windows ------------------------------------------------------------------------ r10905 | roboos | 2015-11-17 18:14:12 +0100 (Tue, 17 Nov 2015) | 2 lines recompiled the mex files on a 32-bit matlab 2011b version on windows 7 (64 bit version of the OS), using MS visual studio express 2010 (version 10.0) ------------------------------------------------------------------------ ------------------------------------------------------------------------ r10903 | roboos | 2015-11-17 18:08:09 +0100 (Tue, 17 Nov 2015) | 2 lines recompiled the mex files with 64-bit matlab 2012b on windows, using MS visual studio 10.0 and SDK71 I hope this makes us robust against 2015b for now. If not, please reopen.