MATLAB Release Notes |
External Interfaces/API Issues
Recompile Fortran MEX-Files
Due to changes in the MATLAB/Fortran interface, Fortran MEX-files that were built with versions of MATLAB prior to Release 12 (MATLAB 6.0) will not work unless they are rebuilt with MATLAB 6.0.
MEX File Compatibility
The Release 12 MATLAB Application Program Interface (API) has several compatibility issues relating to existing MEX-files:
Preference File Location for mex and mbuild
On Windows platforms, the mex
and mbuild
commands now look for their preferences file in
as opposed to the location used by previous versions.
On UNIX platforms, the mex
and mbuild
commands now look for their preferences file in
Therefore, to restore functionality to mex
and mbuild
, you will need to either
mex -setup
and/or mbuild -setup
(easy way), or
Linux MEX-files
For Release 12, you must rebuild Release 11 MEX-files on Linux.
Due to compatibility issues between versions of the GNU standard C libraries, for Linux the file extension for MEX-files is now .mexglx
. The file extension for Release 11 was .mexlx
. This change in file extensions means that the Release 11 MEX-files for Linux will be ignored by Release 12, unless you rebuild the Release 11 MEX-files in Release 12.
SGI MEX-files
You will need to rebuild all MATLAB 5.x C MEX-files on the SGI in MATLAB 6.0 in order to run those MEX-files in MATLAB 6.0. There is no longer a difference between SGI and SGI64 MEX-files; they are all built as n32
.
Unsupported Compilers
MATLAB no longer supports the following compilers:
In addition, The MathWorks will drop support for following compilers in a future version of MATLAB. The MathWorks no longer tests with these compilers:
Using the move Command for ActiveX Controls
In previous versions of MATLAB, the move command returned its first two output variables in reversed order. In the following command,
the returned value pos
, was [y x xsize ysize]
where it should have been [x y xsize ysize]
.
This has been corrected in MATLAB 6.0. If you have changed your code to accommodate the reversed order in earlier versions of MATLAB, you should correct the order of these variables for MATLAB 6.0.
Return Values for Methods Invoked on ActiveX Objects
In previous releases of MATLAB, invoking a method on an ActiveX object always returned a value of type double
. Given the example,
instead of returning an int32
value in val
, MATLAB converted the type of the object obtained from COM to a double
.
MATLAB 6.0 returns the same type of object that was passed to it from COM during method invocation. For example, in R12, val
will be an int32
value instead of a double
.
This was done to be consistent with the method signature for a given method. The method signatures for all methods of an interface can be obtained using invoke
on the handle to an ActiveX object. For example,
will list all methods and their signatures for the mwsamp
control.
If you prefer the former behavior, where MATLAB converts the return value to double
, you will need to explicitly call double
on the method parameter you wish to convert. For example,
mex Function Now Returns Accurate Error Status
now throws an error when it encounters an error condition.
now returns a nonzero value to stat when it encounters an error condition.
In the past, on Microsoft Windows platforms, mex
always either successfully exited or returned zero (indicating success), regardless of whether an error had actually occurred.
To ensure code from before Release 12 works properly in Release 12, either use try/catch
logic to deal with error conditions, or use a form of mex
that returns an error status instead of throwing an error. Specifically
Using engEvalString with GUI-Intensive Applications
If you have graphical user interface (GUI) intensive applications that execute a lot of callbacks through the MATLAB engine, you should force these callbacks to be evaluated in the context of the base workspace. Use evalin
to specify that the base workspace is to be used in evaluating the callback expression, as follows.
Specifying the base workspace in this manner ensures that MATLAB will process the callback correctly and return results for that call.
This does not apply to computational applications that do not execute callbacks.
Starting MATLAB in gdb on GLINUX
If you debug MATLAB using gdb
on a GLINUX system, your session will stop execution whenever it creates a new thread. You can avoid these interruptions by telling the system not to stop on SIGCONT
events. You can then proceed to debug your MATLAB code using nodesktop
mode. You will still be notified whenever a new thread is created, but your session will continue to run without interruption.
Use the following statement in gdb
to turn off triggering on SIGCONT
events.
You can choose to debug in gdb
without specifying SIGCONT
nostop
, but you will have to type continue
at each interruption to proceed with your session. The following is a sample debug session in which SIGCONT
nostop
is specified.
% matlab -Dgdb (gdb) handle SIGCONT nostop Signal Stop Print Pass to program Description SIGCONT No Yes Yes Continued (gdb) run -nodesktop [New Thread 4219] Program received signal SIGCONT, Continued. [New Thread 4220] Program received signal SIGCONT, Continued.
MEX-File Extension Changes
The MEX-file extensions have changed for the Linux, SGI, and HP700 platforms for MATLAB 6.0.
Platform |
Pre-6.0 Extension |
Extension for MATLAB 6.0 |
Linux |
.mexlx |
.mexglx |
SGI |
.mexsg |
.mexsg (no change) |
SGI64 |
.mexsg64 |
.mexsg |
HPUX 11.x |
.mexhp7 |
.mexhpux |
HPUX 10.20 |
.mexhp7 |
.mexhp7 (no change) |
Obsolete C Language MEX Functions
The following API function is obsolete and should not be used in MATLAB programs. This function may not be available in a future version of MATLAB.
Programming and Data Types Issues | Creating Graphical User Interfaces - Upgrade Issues |