JIT session error: symbols not found

[0xchase]

Using the COM API, I get the following error compiling examples/SineSynth upon calling link().

JIT session error: Symbols not found: [ powf, sinf, exp2f ]
Expected<T> must be checked before access or destruction.
Unchecked Expected<T> contained error:
Failed to materialize symbols: { (main, { _sendEvent_midiIn, initialise, advanceBlock }) }Aborted (core dumped)

I get this error on Ubuntu Linux but not on Mac.

How are powf, sinf, and exp2f supposed to be linked into the JIT? Any idea what might be going on?

[cesaref]

That's interesting. I've just built and run the RenderPatch example that's included, and run it against the SineSynth example, and it runs without problem (rendering a few empty frames, which is what you'd expect with no midi in).

Can you recreate that on your setup and confirm that this works? If not, i'd be very interested to know what your machine setup is, as we test on various linux platforms (including Ubuntu) but maybe not all.

If it does work, then maybe the next step would be to look through the way the Patch API works, and see if you can spot what's happening differently.

Normally we have pow/sin/exp2 replaced by intrinsics by the JIT backend, so functions are not used. However, if you are targeting wasm then these don't exist, so there are code paths and logic to substitute in libc style functions in this case, but i'd be surprised if you are going down that route, so it's an interesting question, why they are appearing. Let's see if RenderPatch works first and go from there...

[0xchase]

Hmmm I just successfully built and ran the RenderPatch example. I'm not targeting WASM.

At a high-level, my API calls are:

contents = File::read("SineSynth.cmajor")

program = Program::new()
program.parse(contents)

engine = Engine::create(...)
engine.load(program, ...)
engine.link(...)

I assumed we don't have to parse each of the standard library files.

I'll take some time to look through the patch API again!

[cesaref]

Try modifying one of the native app examples, like DynamicGain by dropping the source of SineSynth.cmajor into the project, and see what happens. Are you getting any endpoint handles between load and link?

[0xchase]

A modified DynamicGain works as expected. It looks like the native app examples statically link rather than dynamically load the cmajor backend? Perhaps that's a relevant difference.

I get the same error both with and without retrieving the endpoints between load and link.

[cesaref]

Sorry for the delay, we've been at ADC.

If you have the examples built, the RenderPatch has a dynamic lib version, RenderPatchSharedLib which you run by giving it a path to the library as a lib, so try that. If both RenderPatch and RenderPatchSharedLib work, then the problem is not a static vs dynamic lib issue. Maybe it's best to post me the code that you are trying to run, and I can investigate, as it does appear to be working as expected with the test cases.

[0xchase]

The RenderPatchSharedLib worked for me.

Just noticed @JamesHallowell thumbed up this issue and that he's developing Rust bindings as well :eyes:. Looking at his repo, it looks like he's run into the same issue.

[JamesHallowell]

Looking at his repo, it looks like he's run into the same issue.

Hey, sorry I meant to leave a comment on this thread and got sidetracked!

Yeah had a look to see if I could repro this too and was seeing the same error on Ubuntu. I tried to minimise the Cmajor program and ended up with this:

processor Repro {
    input value float in;
    output value float out;

    void main() {
        loop {
            out <- in ** in;
            advance();
        }
    }
}

With this program it cannot find the powf symbol.