Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jitter Linking Strategy Improvements #156

Open
tap opened this issue Jul 30, 2020 · 5 comments
Open

Jitter Linking Strategy Improvements #156

tap opened this issue Jul 30, 2020 · 5 comments
Labels

Comments

@tap
Copy link
Contributor

tap commented Jul 30, 2020

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
Copy link
Contributor

x37v commented Jul 30, 2020

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
Copy link
Contributor

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
Copy link
Contributor

x37v commented Jul 31, 2020

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
Copy link
Contributor Author

tap commented Aug 5, 2020

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?

@robtherich robtherich added the bug label Jan 25, 2021
@bltzr
Copy link

bltzr commented Feb 5, 2022

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants