MATLAB®

Advanced Topics

Help Files

Because the MATLAB^® interpreter chooses the binary MEX-file when both an M-file and a MEX-file with the same name are encountered in the same directory, it is possible to use M-files for documenting the behavior of your binary MEX-files. The help command automatically finds and displays the appropriate M-file when help is requested and the interpreter finds and executes the corresponding binary MEX-file when the function is invoked.

Back to Top

Linking Multiple Files

You can combine multiple source files, object files, and file libraries to build a binary MEX-file. To do this, list the additional files, with their file extensions, separated by spaces. The name of the resulting MEX-file is the name of the first file in the list.

The following command combines multiple files of different types into a binary MEX-file called circle.ext, where ext is the extension corresponding to the current platform:

mex circle.c square.obj rectangle.c shapes.lib

You may find it useful to use a software development tool like MAKE to manage MEX-file projects involving multiple source files. Simply create a MAKEFILE that contains a rule for producing object files from each of your source files, and then invoke the mex build script to combine your object files into a binary MEX-file. This way you can ensure that your source files are recompiled only when necessary.

Back to Top

Workspace for MEX-File Functions

Unlike M-file functions, MEX-file functions (binary MEX-files) do not have their own variable workspace. MEX-file functions operate in the caller's workspace. mexEvalString evaluates the string in the caller's workspace. In addition, you can use the mexGetVariable and mexPutVariable routines to get and put variables into the caller's workspace.

Back to Top

Handling Large mxArrays

Binary MEX-files built on 64-bit platforms can handle 64-bit mxArrays. These large data arrays can have up to 2⁴⁸–1 elements. The maximum number of elements a sparse mxArray can have is 2⁴⁸-2.

Using the following instructions creates platform-independent binary MEX-files as well.

Your system configuration can impact the performance of MATLAB. The 64-bit processor requirement enables you to create the mxArray and access data in it. However, your system's memory, in particular the size of RAM and virtual memory, determine the speed at which MATLAB processes the mxArray. The more memory available, the faster the processing.

The amount of RAM also limits the amount of data you can process at one time in MATLAB. For guidance on memory issues, see Strategies for Efficient Use of Memory in the Programming Fundamentals documentation. Memory management within source MEX-files can have special considerations, as described in Memory Management.

Using the 64-Bit API

To work with a 64-bit mxArray, your source code must comply with the 64-bit API, which consists of the functions in the following table.

Functions in this API use the mwIndex and mwSize types. For information about using these macros, see Required Header Files.

Building the Binary MEX-File

Use the , illustrates memory requirements of large mxArrays. To see the example, open the file in MATLAB Editor.

This function requires one positive scalar numeric input, which it uses to create a square matrix. It checks the size of the input to make sure your system can theoretically create a matrix of this size. If the input is valid, it displays the size of the mxArray in kilobytes.

To build this MEX-file, type:

mex -largeArrayDims arraySize.c

To run the MEX-file, type:

arraySize(2^10)

If your system has enough available memory, MATLAB displays:

Dimensions: 1024 x 1024
Size of array in kilobytes: 1024

If your system does not have enough memory to create the array, MATLAB displays an Out of memory error.

You can experiment with this function to test the performance and limits of handling large arrays on your system.

Caution Using Negative Values

When using the 64-bit API, mwSize and mwIndex are equivalent to size_t in C or INTEGER*8 in Fortran. These types are unsigned, unlike int and INTEGER*4, which are the types used in the 32-bit API. Be careful not to pass any negative values to functions that take mwSize or mwIndex arguments. Do not cast negative int or INTEGER*4 values to mwSize or mwIndex; the returned value can not be predicted. Instead, change your code to avoid using negative values.

Building Cross-Platform Applications

If you develop cross-platform applications (programs that can run on both 32- and 64-bit architectures), you must pay attention to the upper limit of values you use for mwSize and mwIndex. The 32-bit application reads these values and assigns them to variables declared as int in C or INTEGER*4 in Fortran. Be careful to avoid assigning a large mwSize or mwIndex value to an int, INTEGER*4, or other variable that might be too small.

Back to Top

Memory Management

Memory management in MEX-files is similar to memory management in any C or Fortran application. However, there are special considerations because a binary MEX-file exists within the context of a larger application, i.e., MATLAB.

• Automatic Cleanup of Temporary Arrays

• Persistent Arrays

• Hybrid Arrays

To avoid common problems related to memory management, see Memory Management Issues.

Automatic Cleanup of Temporary Arrays

When a binary MEX-file returns control to MATLAB, it returns the results of its computations in the output arguments—the mxArrays contained in the left-hand side arguments plhs[]. MATLAB destroys any mxArray created by the MEX-file that is not in this argument list. In addition, MATLAB frees any memory that was allocated in the MEX-file using the mxCalloc, mxMalloc, or mxRealloc functions.

In general, we recommend that MEX-file functions destroy their own temporary arrays and free their own dynamically allocated memory. It is more efficient to perform this cleanup in the source MEX-file than to rely on the automatic mechanism. However, there are several circumstances in which the MEX-file does not reach its normal return statement.

The normal return is not reached if:

• A call to mexErrMsgTxt occurs.

• A call to mexCallMATLAB occurs and the function being called creates an error. (A source MEX-file can trap such errors by using the mexSetTrapFlag function, but not all MEX-files necessarily need to trap errors.)

• The user interrupts the binary MEX-file's execution using Ctrl+C.

• The binary MEX-file runs out of memory. When this happens, the MATLAB out-of-memory handler immediately terminates the MEX-file.

A careful MEX-file programmer can ensure safe cleanup of all temporary arrays and memory before returning in the first two cases, but not in the last two cases. In the last two cases, the automatic cleanup mechanism is necessary to prevent memory leaks.

Persistent Arrays

You can exempt an array, or a piece of memory, from the MATLAB automatic cleanup by calling mexMakeArrayPersistent or mexMakeMemoryPersistent. However, if a binary MEX-file creates such persistent objects, there is a danger that a memory leak could occur if the MEX-file is cleared before the persistent object is properly destroyed. To prevent this from happening, a source MEX-file that creates persistent objects should register a function, using the mexAtExit function, which disposes of the objects. (You can use a mexAtExit function to dispose of other resources as well; for example, you can use mexAtExit to close an open file.)

For example, here is a simple source MEX-file that creates a persistent array and properly disposes of it.

#include "mex.h"

static int initialized = 0;
static mxArray *persistent_array_ptr = NULL;

void cleanup(void) {
    mexPrintf("MEX-file is terminating, destroying array\n");
    mxDestroyArray(persistent_array_ptr);
}

void mexFunction(int nlhs,
    mxArray *plhs[],
    int nrhs,
    const mxArray *prhs[])
{
  if (!initialized) {
    mexPrintf("MEX-file initializing, creating array\n");
        
    /* Create persistent array and register its cleanup. */
    persistent_array_ptr = mxCreateDoubleMatrix(1, 1, mxREAL);
    mexMakeArrayPersistent(persistent_array_ptr);
    mexAtExit(cleanup);
    initialized = 1;

    /* Set the data of the array to some interesting value. */
    *mxGetPr(persistent_array_ptr) = 1.0;
  } else {
    mexPrintf("MEX-file executing; value of first array 
        element is %g\n", *mxGetPr(persistent_array_ptr));
  }
}

Hybrid Arrays

Functions such as mxSetPr, mxSetData, and mxSetCell allow the direct placement of memory pieces into an mxArray. mxDestroyArray destroys these pieces along with the entire array. Because of this, it is possible to create an array that cannot be destroyed, i.e., an array on which it is not safe to call mxDestroyArray. Such an array is called a hybrid array, because it contains both destroyable and nondestroyable components.

For example, it is not legal to call mxFree (or the ANSI^® free() function, for that matter) on automatic variables. Therefore, in the following code fragment, pArray is a hybrid array.

mxArray *pArray = mxCreateDoubleMatrix(0, 0, mxREAL);
double data[10];

mxSetPr(pArray, data);
mxSetM(pArray, 1);
mxSetN(pArray, 10);

Another example of a hybrid array is a cell array or structure, one of whose children is a read-only array (an array with the const qualifier, such as one of the inputs to the MEX-file). The array cannot be destroyed because the input to the MEX-file would also be destroyed.

Because hybrid arrays cannot be destroyed, they cannot be cleaned up by the automatic mechanism outlined in Automatic Cleanup of Temporary Arrays. As described in that section, the automatic cleanup mechanism is the only way to destroy temporary arrays in case of a user interrupt. Therefore, temporary hybrid arrays are illegal and can cause your binary MEX-file to crash. Although persistent hybrid arrays are viable, it is best to avoid using them whenever possible.

Back to Top

Large File I/O

MATLAB supports the use of 64-bit file I/O operations in your MEX-file programs. This enables you to read and write data to files that are up to and greater than 2 GB (2 ^31-1 bytes) in size. Note that some operating systems or compilers might not support files larger than 2 GB.

This section covers the following topics on large file I/O:

• Prerequisites to Using 64-Bit I/O

• Specifying Constant Literal Values

• Opening a File

• Printing Formatted Messages

• Replacing fseek and ftell with 64-Bit Functions

• Determining the Size of an Open File

• Determining the Size of a Closed File

Prerequisites to Using 64-Bit I/O

This section describes the components you need to use 64-bit file I/O in your MEX-file programs:

• Header File

• Type Declarations

• Functions

Header File.   Header file io64.h defines many of the types and functions required for 64-bit file I/O. The statement to include this file must be the first #include statement in your source file and must also precede any system header include statements:

#include "io64.h"
#include "mex.h"
        .
        .
        .

Type Declarations.   Use the following types to declare variables used in 64-bit file I/O.

Functions.   Here are the functions you need for 64-bit file I/O. All are defined in the header file io64.h.

Specifying Constant Literal Values

To assign signed and unsigned 64-bit integer literal values, use type definitions int64_T and uint64_T.

On UNIX systems, to assign a literal value to an integer variable where the value to be assigned is greater than 2 ³¹-1 signed, you must suffix the value with LL. If the value is greater than 2 ³²-1 unsigned, then use LLU as the suffix. These suffixes apply only to UNIX systems and are considered invalid on the Microsoft^® Windows^® systems.

Note   The LL and LLU suffixes are not required for hardcoded (literal) values less than 2 G (2 31-1), even if they are assigned to a 64-bit int type.

The following example declares a 64-bit integer variable initialized with a large literal int value, and two 64-bit integer variables:

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, 
                  const mxArray *prhs[])
{
#if defined(_MSC_VER) || defined(__BORLANDC__)     /* Windows */
   int64_T large_offset_example = 9000222000;
#else                                              /* UNIX    */
   int64_T large_offset_example = 9000222000LL;
#endif

int64_T offset   = 0;
int64_T position = 0;

Opening a File

To open a file for reading or writing, use the C fopen function as you normally would. As long as you have included io64.h at the start of your program, fopen works correctly for large files. No changes at all are required for fread, fwrite, fprintf, fscanf, and fclose.

To open an existing file for read and update in binary mode:

fp = fopen(filename, "r+b");
if (NULL == fp)
   {
   /* File does not exist. Create new file for writing 
    * in binary mode.
    */
   fp = fopen(filename, "wb");
   if (NULL == fp)
      {
      sprintf(str, "Failed to open/create test file '%s'",
              filename);
      mexErrMsgTxt(str);
      return;
      }
   else
      {
      mexPrintf("New test file '%s' created\n",filename);
      }
   }
else mexPrintf("Existing test file '%s' opened\n",filename);

Printing Formatted Messages

You cannot print 64-bit integers using the %d conversion specifier. Instead, use FMT64 to specify the appropriate format for your platform. FMT64 is defined in the header file tmwtypes.h. The following example shows how to print a message showing the size of a large file:

int64_T large_offset_example = 9000222000LL;

mexPrintf("Example large file size: %" FMT64 "d bytes.\n",
           large_offset_example);

Replacing fseek and ftell with 64-Bit Functions

The ANSI C fseek and ftell functions are not 64-bit file I/O capable on most platforms. The functions setFilePos and getFilePos, however, are defined as the corresponding POSIX fsetpos and fgetpos, (or fsetpos64 and fgetpos64), as required by your platform/OS. These functions are 64-bit file I/O capable on all platforms.

The following example shows how to use setFilePos instead of fseek, and getFilePos instead of ftell. It uses getFileFstat to find the size of the file, and then uses setFilePos to seek to the end of the file to prepare for adding data at the end of the file.

Note    Although the offset parameter to setFilePos and getFilePos is really a pointer to a signed 64-bit integer, int64_T, it must be cast to an fpos_T*. The fpos_T type is defined in io64.h as the appropriate fpos64_t or fpos_t, as required by your platform/OS.

getFileFstat(fileno(fp), &statbuf);
fileSize = statbuf.st_size;
offset = fileSize;

setFilePos(fp, (fpos_T*) &offset);
getFilePos(fp, (fpos_T*) &position );

Unlike fseek, setFilePos supports only absolute seeking relative to the beginning of the file. If you want to do a relative seek, first call getFileFstat to obtain the file size, and then convert the relative offset to an absolute offset that you can pass to setFilePos.

Determining the Size of an Open File

Getting the size of an open file involves two steps:

1. Refresh the record of the file size stored in memory using getFilePos and setFilePos.

2. Retrieve the size of the file using getFileFstat.

Refreshing the File Size Record.   Before attempting to retrieve the size of an open file, you should first refresh the record of the file size residing in memory. If you skip this step on a file that is opened for writing, the file size returned might be incorrect or 0.

To refresh the file size record, seek to any offset in the file using setFilePos. If you do not want to change the position of the file pointer, you can seek to the current position in the file. This example obtains the current offset from the start of the file, and then seeks to the current position to update the file size without moving the file pointer:

getFilePos( fp, (fpos_T*) &position);
setFilePos( fp, (fpos_T*) &position);

Getting the File Size.   The getFileFstat function takes a file descriptor input argument (that you can obtain from the file pointer of the open file using fileno) and returns the size of that file in bytes in the st_size field of a structStat structure:

structStat statbuf;
int64_T fileSize = 0;

if (0 == getFileFstat(fileno(fp), &statbuf))
   {
   fileSize = statbuf.st_size;
   mexPrintf("File size is %" FMT64 "d bytes\n", fileSize);
   }

Determining the Size of a Closed File

The getFileStat function takes the filename of a closed file as an input argument and returns the size of the file in bytes in the st_size field of a structStat structure:

structStat statbuf;
int64_T fileSize = 0;

if (0 == getFileStat(filename, &statbuf))
   {
   fileSize = statbuf.st_size;
   mexPrintf("File size is %" FMT64 "d bytes\n", fileSize);
   }

Back to Top

Using LAPACK and BLAS Functions

LAPACK is a large, multiauthor Fortran subroutine library that MATLAB uses for numerical linear algebra. BLAS, which stands for Basic Linear Algebra Subroutines, is used by MATLAB to speed up matrix multiplication and the LAPACK routines themselves. The functions provided by LAPACK and BLAS can also be called directly from within your C source MEX-files.

This section explains how to write and build MEX-files that call LAPACK and BLAS functions. It provides information on

• Specifying the Function Name

• Calling LAPACK and BLAS Functions from C

• Handling Complex Numbers

• Preserving Input Values from Modification

• Building the C MEX-File

• Example — Symmetric Indefinite Factorization Using LAPACK

• Calling LAPACK and BLAS Functions from Fortran

• Building the Fortran MEX-File

Specifying the Function Name

When calling an LAPACK or BLAS function, some platforms require an underscore character following the function name in the call statement.

On the Microsoft Windows platform use the function name alone, with no trailing underscore. For example, to call the LAPACK dgemm function, use:

dgemm(arg1, arg2, ..., argn);

On the Sun™ Solaris™, Linus Torvalds' Linux^®, and Apple^®Macintosh^® platforms, add the underscore after the function name. For example, to call dgemm on any of these platforms, use:

dgemm_(arg1, arg2, ..., argn);

Calling LAPACK and BLAS Functions from C

Since the LAPACK and BLAS functions are written in Fortran, arguments passed to and from these functions must be passed by reference. The following example calls dgemm, passing all arguments by reference. An ampersand (&) precedes each argument unless that argument is already a reference.

#include "mex.h"

void mexFunction(int nlhs, mxArray *plhs[],
                 int nrhs, const mxArray *prhs[])
{
  double *A, *B, *C, one = 1.0, zero = 0.0;
  mwSize m,n,p; 
  char *chn = "N";

  A = mxGetPr(prhs[0]);
  B = mxGetPr(prhs[1]);
  m = mxGetM(prhs[0]);
  p = mxGetN(prhs[0]);
  n = mxGetN(prhs[1]);

  if (p != mxGetM(prhs[1])) {mexErrMsgTxt
    ("Inner dimensions of matrix multiply do not match");
  }

  plhs[0] = mxCreateDoubleMatrix(m, n, mxREAL);
  C = mxGetPr(plhs[0]);

  /* Pass all arguments to Fortran by reference */
  dgemm(chn, chn, &m, &n, &p, &one, A, &m, B, &p, &zero, C, &m);
}

Handling Complex Numbers

Caution   Use care when using level 1 BLAS functions (e.g. ZDOTU, ZDOTC) with complex numbers in a C program MEX-file.

MATLAB stores complex numbers differently than Fortran. MATLAB stores the real and imaginary parts of a complex number in separate, equal length vectors, pr and pi. Fortran stores the same number in one location with the real and imaginary parts interleaved.

As a result, complex variables exchanged between MATLAB and the Fortran functions in LAPACK and BLAS are incompatible. MATLAB provides conversion routines that change the storage format of complex numbers to address this incompatibility.

Input Arguments.   For all complex variables passed as input arguments to a Fortran function, you need to convert the storage of the MATLAB variable to be compatible with the Fortran function. Use the mat2fort function for this. See the example that follows.

Output Arguments.   For all complex variables passed as output arguments to a Fortran function, you need to do the following:

1. When allocating storage for the complex variable, allocate a real variable with twice as much space as you would for a MATLAB variable of the same size. You need to do this because the returned variable uses the Fortran format, which takes twice the space. See the allocation of zout in the example that follows.

2. Once the variable is returned to MATLAB, convert its storage so that it is compatible with MATLAB. Use the fort2mat function for this.

Example — Passing Complex Variables.   The example below shows how to call an LAPACK function from MATLAB, passing complex prhs[0] as input and receiving complex plhs[0] as output. Temporary variables zin and zout are used to hold prhs[0] and plhs[0] in Fortran format.

#include "mex.h" 
#include "fort.h"      /* defines mat2fort and fort2mat */

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, mxArray 
*prhs[])
{ 
  mwSize lda, n; 
  double *zin, *zout;
  lda = mxGetM(prhs[0]); 
  n = mxGetN(prhs[0]); 

  /* Convert input to Fortran format */
  zin = mat2fort(prhs[0], lda, n);

  /* Allocate a real, complex, lda-by-n variable to store output 
*/
  zout = mxCalloc(2*lda*n, sizeof(double));

  /* Call complex LAPACK function */ 
  zlapack_function(zin, &lda, &n, zout);

  /* Convert output to MATLAB format */ 
  plhs[0] = fort2mat(zout, lda, lda, n);

  /* Free intermediate Fortran format arrays */ 
  mxFree(zin);
  mxFree(zout); 
}

Preserving Input Values from Modification

Many LAPACK and BLAS functions modify the values of arguments passed in to them. It is advisable to make a copy of arguments that can be modified prior to passing them to the function. For complex inputs, this point is moot since the mat2fort version of the input is a new piece of memory, but for real data this is not the case.

The following example calls an LAPACK function that modifies the first input argument. The code in this example makes a copy of prhs[0], and then passes the copy to the LAPACK function to preserve the contents of prhs[0].

/* lapack_function modifies A so make a copy of the input */ 
m = mxGetM(prhs[0]); 
n = mxGetN(prhs[0]); 
A = mxCalloc(m*n, sizeof(double)); 

/* Copy mxGetPr(prhs[0]) into A */ 
temp = mxGetPr(prhs[0]); 
for (k = 0; k < m*n; k++) { 
   A[k] = temp[k]; 
   }

/* lapack_function does not modify B 
/* so it is OK to use the input 
directly */ 
B = mxGetPr(prhs[1]);
lapack_function(A, B);       /* modifies A but not B */

/* Free A when you are done with it */ 
mxFree(A);

Building the C MEX-File

The examples in this section show how to compile and link a C source MEX file myCmexFile.c on the platforms supported by MATLAB.

Building on Windows^® Systems.   If you build your C MEX-file on a Windows platform, you need to explicitly specify a library file to link with.

On a Windows system, use this command if you are using the Lcc compiler that ships with MATLAB:

mex myCmexFile.c matlabroot\extern\lib\win32\lcc\libmwlapack.lib
matlabroot\extern\lib\win32\lcc\libmwblas.lib

Or, use this command if you are using the Microsoft^® Visual C++^® compiler:

mex myCmexFile.c 
matlabroot\extern\lib\win32\microsoft\libmwlapack.lib
matlabroot\extern\lib\win32\microsoft\libmwblas.lib

or:

mex myCmexFile.c 
matlabroot\extern\lib\win64\microsoft\libmwlapack.lib
matlabroot\extern\lib\win64\microsoft\libmwblas.lib

Building on Other Operating Systems.   On all other platforms, you can build your MEX-file as you would any other C source MEX-file. For example:

mex myCmexFile.c -lmwlapack -lmwblas

MEX-File Functions That Perform Complex Number Conversion.   MATLAB supplies the files fort.c and fort.h, which provide routines for conversion between MATLAB and FORTRAN complex data structures. These files define the mat2fort and fort2mat routines mentioned previously under Handling Complex Numbers.

If your program uses these routines, you need to:

1. Include the fort.h file in your program using #include "fort.h". See Example — Passing Complex Variables.

2. Build the fort.c file with your program. Specify the path, matlabroot/extern/examples/refbook for both fort.c and fort.h in the build command.

On Windows systems, use either one of the following:

1. mex myCmexFile.c matlabroot/extern/examples/refbook/fort.c 
   -Imatlabroot/extern/examples/refbook 
   matlabroot/extern/lib/win32/microsoft/libmwlapack.lib
   matlabroot/extern/lib/win32/microsoft/libmwblas.lib
   

2. mex myCmexFile.c matlabroot/extern/examples/refbook/fort.c 
   -Imatlabroot/extern/examples/refbook 
   matlabroot/extern/lib/win32/lcc/libmwlapack.lib
   matlabroot/extern/lib/win32/lcc/libmwblas.lib

For all other platforms, use:

mex myCmexFile.c matlabroot/extern/examples/refbook/fort.c 
-Imatlabroot/extern/examples/refbook 

Example — Symmetric Indefinite Factorization Using LAPACK

The directory matlabroot/extern/examples/refbook contains an example C source MEX-file that calls two LAPACK functions. There are two versions of this file:

• utdu_slv.c - calls functions zhesvx and dsysvx, and thus is compatible with the Windows platform.

• utdu_slv_.c - calls functions zhesvx_ and dsysvx_, and thus is compatible with the Linux, Solaris, and Macintosh platforms.

Calling LAPACK and BLAS Functions from Fortran

You can make calls to the LAPACK and BLAS functions used by MATLAB from your Fortran MEX files. The following is an example program that takes two matrices and multiplies them by calling the LAPACK routine, dgemm:

      subroutine mexFunction(nlhs, plhs, nrhs, prhs)
      mwPointer plhs(*), prhs(*)
      integer nlhs, nrhs
      mwPointer mxcreatedoublematrix
      mwPointer mxgetpr
      mwPointer A, B, C
      mwSize mxgetm, mxgetn
      mwSize m, n, p, numel
      double precision one, zero, ar, br
      character ch1, ch2

      ch1 = 'N'
      ch2 = 'N'
      one = 1.0
      zero = 0.0

      A = mxgetpr(prhs(1))
      B = mxgetpr(prhs(2))
      m = mxgetm(prhs(1))
      p = mxgetn(prhs(1))
      n = mxgetn(prhs(2))

      plhs(1) = mxcreatedoublematrix(m, n, 0.0)
      C = mxgetpr(plhs(1))
      numel = 1
      call mxcopyptrtoreal8(A, ar, numel)
      call mxcopyptrtoreal8(B, br, numel)

      call dgemm(ch1, ch2, m, n, p, one, %val(A), m,
     +           %val(B), p, zero, %val(C), m)

      return
      end

Building the Fortran MEX-File

The examples in this section show how to compile and link a Fortran MEX file, myFortranmexFile.F, on the platforms supported by MATLAB.

Building on the Windows^® Platform.   On the Windows platform, using Visual Fortran, link against the libraries libdflapack.lib and libdfblas.lib:

mex -v myFortranMexFile.F 
matlabroot/extern/lib/win32/microsoft/libdflapack.lib
matlabroot/extern/lib/win32/microsoft/libdfblas.lib

Building on Other UNIX^® Platforms.   On the UNIX platforms, create the MEX file as follows:

mex -v myFortranMexFile.F -lmwlapack -lmwblas

^[a] UNIX is a registered trademark of The Open Group in the United States and other countries.

Back to Top

Examples of C Source MEX-Files

Debugging C Language MEX-Files