Jitter Linking Strategy Improvements

[tap]

Currently we always link against the JitterAPI framework.

On the Mac (at least) we have the option of linking, or rather not linking, as we do for the MaxAPI and MaxAudioAPI. This may have some benefits as discussed with @x37v

[x37v]

my naive approach for creating this linker file, nm -gU JitterAPI > jitsymb.txt then edit to wrap symbol with '-Wl,-U, and ' doesn't work on osx because it exceeds the argument limit (we get a failure while linking). Maybe I'm including too many symbols anyway? I assume "-undefined dynamic_lookup" is just too permissive?

[timblechmann]

doesn't work on osx because it exceeds the argument limit

does it help to pass the arguments via a response file?

---

allowing undefined symbols in one way or another is a little ugly and in a perfect world an interface struct with function pointers is passed to the external when loading (either as POD c-style struct or as c++ class with virtual functions). furthermore it's cross-platform

[x37v]

doesn't work on osx because it exceeds the argument limit

does it help to pass the arguments via a response file?

I noticed a bug (SHARED_LINKER_FLAGS being included in MODULE_LINKER_FLAGS) and once I resolved that both response files and the big string approach worked.

    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${C74_SYM_MAX_LINKER_FLAGS} ${C74_SYM_MSP_LINKER_FLAGS}")
    set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${C74_SYM_MAX_LINKER_FLAGS} ${C74_SYM_MSP_LINKER_FLAGS}")
    set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${C74_SYM_MAX_LINKER_FLAGS} ${C74_SYM_MSP_LINKER_FLAGS}")

thanks @timblechmann

@tap is there any reason to link against the JitterAPI framework now that I've added these symbols or should I remove that entirely?

[tap]

Was thinking I had already responded to this -- maybe I did in a different channel -- but I agree we should not need to link against the JitterAPI framework on the Mac.

On Windows I suspect we still need to link against lib, but maybe there is another strategy available to use there too?

[bltzr]

Hi there, I don’t know if this is related (I guessed it was), but I get those issues when trying to build one of my projects (not using Jitter functions in any way) on my M1 Mac. I have updated (recursively) min-api and submodules.

Ignoring file /path_to_my_project/source/min-api/max-api/lib/mac/JitterAPI.framework/JitterAPI, missing required architecture arm64 in file /path_to_my_project/source/min-api/max-api/lib/mac/JitterAPI.framework/JitterAPI (2 slices)
Undefined symbol: _jit_class_addattr

Any idea why this is happening and how to solve it ?