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

not working in macOS #49

Closed
dimitre opened this issue Mar 12, 2024 · 14 comments
Closed

not working in macOS #49

dimitre opened this issue Mar 12, 2024 · 14 comments

Comments

@dimitre
Copy link
Contributor

dimitre commented Mar 12, 2024

I've made some changes in a fork to make it work locally
basically I've renamed libs/NDI/export to libs/NDI/lib
updated addon_config.mk
and copied libndi.dylib to libs/NDI/lib/osx
https://github.com/dimitre/ofxNDI

@leadedge
Copy link
Owner

Thanks Dimitre,
ofxNDIdynloader uses the installed NDI runtime to find the required dll.
Does this mean that the runtime installation fails to install the required file? "libndi.dylib"?

@dimitre
Copy link
Contributor Author

dimitre commented Mar 14, 2024

Yes, the installed installs the lib in /usr/local/lib/libndi.dylib
and ofxNDIdynloader was trying in two different paths. I can test later and report which paths
but none of them were /usr/local/lib/libndi.dylib

@leadedge
Copy link
Owner

I think this could be a more significant problem.
Loading from a local file is a workaround and finding the cause is best in the long run.

@eduardfrigola
@moebiussurfing
any ideas?

@leadedge
Copy link
Owner

Any results on this?

I have updated the NDI include and dll files to 5.6.1.

For Windows, I can confirm that the runtime installer downloads correctly from "http://ndi.link/NDIRedistV5" and installs to "C:\Program Files\NDI\NDI 5 Runtime\v5" and the environment variable used by ofxNDIdynLoader "NDI_RUNTIME_DIR_V5" is the same path.

@leadedge
Copy link
Owner

leadedge commented Apr 10, 2024

Another update to NDI 6.0.0.0
I confirmed for Windows that the new runtime installer downloads from http://ndi.link/NDIRedistV6, installs to "C:\Program Files\NDI\NDI 6 Runtime\v6" and the environment variables "NDI_RUNTIME_DIR_V5" and "NDI_RUNTIME_DIR_V6" are both the same path.
I will close this now, but if you have any further information, please advise here.

@leadedge
Copy link
Owner

Dimitre - did you ever find out what the two different paths were that ofxNDIdynloader was trying?
The dynamic loading must work because I can never update libndi.dylib.

@eduardfrigola
Copy link

Hi @leadedge, sorry for not replying earlier...

When you posted this I tried to replicate the issue with no luck.
I had (still have) a working setup, where I install the libndi in the default location usr/local/lib
In my machine [M2 Max // macOS 13.2.1 // Xcode 14.2] I can open the library as expected with the system dlopen() call.

m_hNDILib = dlopen(ndi_path.c_str(), RTLD_LOCAL | RTLD_LAZY);

But last week I was with another computer using the library, and this problem appeared.
The machine is a M2 Ultra, with macOS 14.2 and Xcode 15.2.
In this machine, when executing via Xcode everything seems fine, but when executing the standalone app, the library not loaded error pops up.

Tying to find an easy workaround for the situation, I found out that using the app build with the previous machine (macOS 13.2.1 / Xcode 14.2) it runs and finds the library as expected, so seems the issue is not with macOS 14.2 but with Xcode 15.2 builds.

Searching the possible issue in that direction I found some things that reaffirmed my suspicions:
https://developer.apple.com/forums/thread/737920
mesonbuild/meson#12288

As I can understand in this threads, usr/local/lib is not a default location for searching paths for dlopen().

All this using libndi 5.6.0. Maybe libndi 6.x.x solves that issue and installs the library in another location?

I still have not resolved the issue when compiling from Xcode 15, @dimitre fork should work, but I will try to make it work with an installed version of libndi instead of a local one.

Eduard

@leadedge
Copy link
Owner

leadedge commented May 15, 2024

Thanks very much Eduard.

The question is what path is returned for the NDI runtime. This is ndi_path returned from FindRuntime(). It should be the same location as for the official installation of the NDI runtime downloaded from http://ndi.link/NDIRedistV6

Correction - that is for windows. It should be

http://ndi.link/NDIRedistV6Apple

We expect this to be usr/local/lib. If the library is installed at this location and ndi_path is the same folder, it should work. If the locations are different, as Dimitri says, this could be another problem related to NDI. It could be a version issue as you suggest.

@leadedge
Copy link
Owner

Some observations.
The NDI SDK documentation says -

On the Mac, it is not possible to specify global environment variable -- the redistributable on MacOS is installed within /usr/local/lib

If that's the case, the result of querying the environment variable might not be correct, and a hard-coded path to /usr/local/lib might be necessary. Also if there is a problem loading a library from /usr/local/lib, can the file be copied to another folder, the executable folder, and loaded from there?

@dimitre
Copy link
Contributor Author

dimitre commented May 16, 2024

I've just tested now again. I've installed libNDI v6 and it is correctly installed in /usr/local/lib
here is the output of ZSH (default shell) export command to show env variables

HOME=/Users/d
HOMEBREW_CELLAR=/opt/homebrew/Cellar
HOMEBREW_PREFIX=/opt/homebrew
HOMEBREW_REPOSITORY=/opt/homebrew
INFOPATH=/opt/homebrew/share/info:
LC_CTYPE=UTF-8
LOGNAME=d
MANPATH=/opt/homebrew/share/man::
OLDPWD=/Users/d
PATH=/opt/homebrew/opt/node@18/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/d/.cargo/bin:/Users/d/ofbuild
PWD=/Users/d
SHELL=/bin/zsh
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.XXXX/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=447.1
TERM_SESSION_ID=A0270C9E-65CC-447B-A89A-70E92AEEA3DF
TMPDIR=/var/folders/8t/mhj0ns1n3j3cmgkkl8q5xk8h0000gp/T/
USER=d
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
__CFBundleIdentifier=com.apple.Terminal
ccache=/opt/homebrew/bin/ccache

and software output

NDI runtime location libndi.dylib
Couldn't load dynamic library at: libndi.dylib

ofxNDI example sender - 32 bit
 (https://www.ndi.tv/)
ofxNDIsend::CreateSender - not initialized

it seems to me it will try to load the library in the same app folder

just as a quick test, it works if I change this define to the full path

#			define NDILIB_LIBRARY_NAME  "/usr/local/lib/libndi.dylib"

@leadedge
Copy link
Owner

Thanks Dimitre,

the NDI runtime environment variable is clearly not in the list, so there is no use in testing for it. If the full path works for you, it can be used directly in "FindRuntime" and I have made the changes to try.

If loading still fails for Xcode 15.2, the library file will have to be copied to the application folder. I have included a section explaining library installation in the readme and can extend that slightly if there is still a problem.

I have found that a re-boot is required before Windows environment variables can be accessed. Fortunately, a registry read works around it until the machine is re-started. I have also changed from deprecated NDIlib_v4* to NDIlib_v5* p_NDILib, changed "libs/NDI/export/vs" to "libs/NDI/bin/vs" to align with the current NDI SDK folder naming and updated to NDI 6.0.1.0. All this is now in the Master branch and hopefully it will get a bit closer to a solution.

@dimitre
Copy link
Contributor Author

dimitre commented May 17, 2024

All good now! working with installed libNDI v6
just fyi, there are some .exe added to the repository

@dimitre
Copy link
Contributor Author

dimitre commented May 17, 2024

Thank you @leadedge

@leadedge
Copy link
Owner

That's good news. Thanks for your time and the heads up on extra files.

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

No branches or pull requests

3 participants