Error using build after clibgen.ge​nerateLibr​aryDefinit​ion runs as expected.

I'm attempting to follow a tutorial for interfacing with C++ libraries in MATLAB. The only major difference between my situation and the author's is that I'm working on a windows machine, meaning that I run

> cl /c rectangle.cpp
> lib /OUT:rectangle.lib rectangle.obj

to compile into a .obj file (rather than .o) and reformat it to .lib. Then, in the MATLAB environment, I run

>> headerFile = "C:\path\to\rectangle.h";
>> libFile = "C:\path\to\rectangle.lib";
>> libName = "rectangle";
>> clibgen.generateLibraryDefinition(headerFile, "Libraries", libFile, "PackageName", libName)

This runs without issue. The generated definerectangle.m looks as I expect, and the summary looks as follows:

>> summary(definerectangle)

MATLAB Interface to rectangle Library

Class clib.rectangle.Rectangle

  Constructors:
    clib.rectangle.Rectangle(double,double,double,double)
    clib.rectangle.Rectangle(clib.rectangle.Rectangle)

  Methods:
    double Area()

  No Properties defined

which seems right. However, when I attempt to build, I get the following result

  >> build(definerectangle)
Building interface file 'rectangleInterface.dll' for clib interface 'rectangle'.
Not enough input arguments.

Error in clibgen.internal.build>delAdditionalFiles (line 1001)
for ind = 1:length(cmdFilesList)
                   ^^^^^^^^^^^^
Error in clibgen.internal.build (line 378)
            delAdditionalFiles(outputDir, srcFileName, dataFileName, buildExecutable, sourceFilesObj, '');
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in clibgen.internal.buildHelper (line 104)
    [status,cmdOut] = clibgen.internal.build(srcFile,cellstr(libraries),cellstr(srcFiles),cellstr(includePath),interfaceDir,obj.DefinedMacros,obj.UndefinedMacros, ...
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in clibgen.LibraryDefinition/build (line 1664)
            clibgen.internal.buildHelper(obj, obj.LibraryInterface, '', directBuild);
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I have checked the mex compiler configuration to see if that might be an issue, but it appears to match what I used to compile with cl.exe

>> mex -setup cpp
MEX configured to use 'Microsoft Visual C++ 2022' for C++ language compilation.

I'm at a loss for what this error could mean, so I would appreciate any help in interpreting it and getting this to work.

Answer 1

[埃博拉酱]

Since you didn't provide the source code, I can't reproduce your issue. But I would suggest that you compile a C++ MEX file function instead of using clibgen. MEX is generally less error-prone and performs better.

20250126

Judging from the error message, this problem may not have much to do with the compiler. It looks like MATLAB recognizes the variable cmdFilesList as a function during the execution of internal code. You may want to check your workspace and search path for issues with this variable or any other name that might be the same as a function built into MATLAB.

[Andrew]

Sorry. To clarify, I'm using the same source code provided in the link

// rectangle.h

class Rectangle
{
private:
	double x, y, width, height;

public:
	Rectangle(double x, double y, double width, double height);
	double Area();

};

and

// rectangle.cpp

#include "rectangle.h"

Rectangle::Rectangle(double x, double y, double width, double height)
{
	this->x = x;
	this->y = y;
	this->width = width;
	this->height = height;
}

double Rectangle::Area()
{
	return this->width * this->height;
}

The steps for generating the .lib file are run in the Visual Studio Developer Command Prompt, and subsequent steps are all run in the MATLAB Command Window. The steps for compiling and reformatting to .lib run without issue, so I don't think there's anything wrong with the source code. What I'm trying to do appears to be identical to the process described in this video released by the official MATLAB youtube channel.

[Andrew]

Still not really sure what the underlying issue was, but I tried it on a different device with the MinGW-w64 compiler instead, and everything seemed to run as expected there. I'll add a comment if I ever work out the source of the issue, but for now I think I can proceed without fully understanding it.

[埃博拉酱]

@Andrew The key is that you switch to a different device and solve the potential duplicate name problem. I still don't think the compiler is the key.