-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
my naive approach for creating this linker file, |
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 |
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.
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? |
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? |
Hi there,
Any idea why this is happening and how to solve it ? |
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
The text was updated successfully, but these errors were encountered: