MATLAB compiler and superiorto

I have a piece of MATLAB code that I'm trying to compile into a standalone. The uncompiled version works fine, but when I compile it and run from a DOS command window, I encounter an error

Unknown class 'SeparableLinearOp' used in builtin function 'SUPERIORTO'

The call to superiorto is in the constructor of a second, old-style class. The class SeparableLinearOp is not being used, so I didn't provide code for it. Because SeparableLinearOp is not being used, the M-code version doesn't care about its absence. Why does the compiled version care?

Answer 1

[Matt J]

After working with tech support, the problem seems to be resolved. Basically, if you call superiorto('ClassA','ClassB',...,'ClassZ'), then definitions for all those classes have to be in the CTF archive. However, as usual, the compilation process isn't always smart enough to know what to include in the archive and you have to force the inclusion of certain things with pragmas. This was the case for SeparableLinearOp, because it was never actually invoked. It just appeared within the list of string arguments to SUPERIORTO.

However, a more convenient solution than adding pragmas was to dynamically detect which classes were present and adjust the superiorto argument list accordingly:

   inferiorClasses={'ClassA','ClassB',...,'ClassZ'};

    oldclasses=cellfun(@(c) exist(['@' c],'dir'), inferiorClasses );
    newclasses=cellfun(@(c) exist(c,'file'), inferiorClasses );

   superiorto(inferiorClasses{oldclasses|newclasses});

It's a bit of a shame, of course, that SUPERIORTO can't just ignore undefined classes. It also would have saved some headache if exist(...,'class') worked on old style classes as well as new ones.

Answer 2

[Image Analyst]

Are you sure it's not being used. Run this:

http://www.mathworks.com/matlabcentral/fileexchange/17291

and really check for it. It might be buried in there unbeknownst to you through a call to a function you don't suspect is using it. Generally you can' compile in modules that have extensive user interfaces with them - for example imtool. When you compile, the excluded log will list files that cannot be included in the compiled versions.

[Matt J]

I'm pretty sure it's not being used because when I test run the MCode version, I've cleaned the path completely. The code can only see what's in my current directory and SeparableLinearOp was not there.

This is digressing slightly from my original question but also, even when I add the @SeparableLinearOp class directory to the project and recompile, the problem persists. The excluded log lists nothing as excluded.

Is there any way to track what files were actually included in the compilation? If I compile with the 'Embed CTF Archive' option unselected, for example, will it unpack all the dependent files somewhere for me to check (and if so where)?

[Image Analyst]

Did you try fdep? It's really comprehensive at listing all the subfunctions that are used.

Issue this command:

fprintf('The secret ctfroot folder is %s\n', ctfroot);

in your startup code for your m-file. When it runs on the target machine, it will show you where that secret location is. Go there and poke around to see what it shipped with your application.

Have you tried all the things in the FAQ? http://matlab.wikia.com/wiki/FAQ#My_standalone_executable_won.27t_run_on_the_target_computer._What_can_I_try.3F If all else fails, you can call tech support - might as well get some support for all the money you spent on the compiler.

[Matt J]

Hmmm. Well, let me add a little more information.

(1) I have a tool very similar to fdep, which I use to extract all my dependent files and send them to an isolated directory where I compile them. Now, you could always suppose that fdep is more thorough, but I don't see how thoroughness could be the issue when

• The uncompiled version of the (extracted) mcode runs fine even in the absence SeparableLinearOp class.
• Afterwards, I added SeparableLinearOp to the isolated directory, but the compiled code still complains that it's missing.

(2) I've yet to try printing ctfroot like you proposed, but I did recompile without embedding the ctf archive. I'm wondering if that's equivalent? When compiled this way and executed, the ctf archive unpacks in a very visible, non-secret location. I cannot find SeparableLinearOp in the archive. The compiler should have been able to include it, if it felt that it was needed.

(3) In case it matters, I'll mention that I'm compiling under a 32-bit MATLAB on a 64-bit machine, because the target machine will be 32-bit. Could that matter??? I've compiled very similar things in the past under 64-bit MATLAB without any problems.

Sigh...I guess tech support might be the last option... It's a good FAQ link, though. I didn't know about "Tools/Show dependency report".

[Image Analyst]

I agree with point 2. If it's one of the Mathworks routines, it should have been there. If it's someone else's it won't be there and you have to ship it separately or have deploytool include it as an extra shippable file. fdep is a lot more comprehensive that the dependency report. Looks like tech support may be your final option. Come back here and report what finally fixes it, or add it to the FAQ's compile problems section.

[Matt J]

You agree with point (2) but not the first bullet point of part (1)? Why would the compiled version need it if the uncompiled version does not?

[Image Analyst]

I didn't disagree with point 1, I just didn't have any comment on it. I have no explanation for what you're seeing. As you know, it makes little sense.