macOS builds use homebrew rpath instead of bundled libraries.

[anijatsu]

Steps to reproduce

1. Have a Baldur's Gate 1 installation ready to go -- in my case it's a Windows install of base game + TOTSC done via Whisky
2. Download and extract a macOS ARM gemrb build
3. Open GemRB.app
4. Select Baldur Gate 1 (original ed. as per no EE support mention) game directory as Game Path 3a. (Toggle Logging option on)
5. Click on Launch
6. Get the undescriptive error message both as a popup and in GemRB.log:

[Core/]: Initializing Video Driver...
[Cocoa Wrapper/FATAL]: Unable to initialize core: No Video Driver Available.. Terminating.

Expected behavior

Information on whether I'm missing any dependencies; info. on how/where to set the SDL path / version.

Screenshots

GemRB version (check as many as you know apply)

• [ x ] master as of this issue
• [ x ] 0.9.2

(I have tried two builds linked on the gemrb website:

• https://sourceforge.net/projects/gemrb/files/Buildbot%20Binaries/Apple/ARM64/gemrb-2023-07-13-7817597b.zip/download
• https://sourceforge.net/projects/gemrb/files/Releases/0.9.2/gemrb-macos-arm64-v0.9.2.zip/download )

Video Driver (check as many as you know apply)

• [ ] SDL1.2
• [ ] SDL2 built with USE_OPENGL_BACKEND
• [ ] SDL2 without USE_OPENGL_BACKEND I do not know, nor can I see a way to check without rebuilding the application myself. I did have sdl2 package installed with home-brew, adding sdl2-gfx and sdl2-image didn't help.

~% brew list | grep sdl
sdl2
sdl2_gfx
sdl2_image
~% brew list sdl2
/opt/homebrew/Cellar/sdl2/2.28.1/bin/sdl2-config
/opt/homebrew/Cellar/sdl2/2.28.1/include/SDL2/ (78 files)
/opt/homebrew/Cellar/sdl2/2.28.1/lib/libSDL2-2.0.0.dylib
/opt/homebrew/Cellar/sdl2/2.28.1/lib/cmake/ (2 files)
/opt/homebrew/Cellar/sdl2/2.28.1/lib/pkgconfig/sdl2.pc
/opt/homebrew/Cellar/sdl2/2.28.1/lib/ (4 other files)
/opt/homebrew/Cellar/sdl2/2.28.1/share/aclocal/sdl2.m4
~% which sdl2-config
/opt/homebrew/bin/sdl2-config

[bradallred]

I'm impressed they run for you at all. They are completely unsigned so they aren't going to run on any Mac that doesn't cripple their security settings (or I guess sign them yourself). I have no idea why we build them that way and I should probably look into how to improve it.

Anyway, I've verified the SDLVideo driver is located inside the app bundle in the Plugins directory and the SDL2 dylib is in the Frameworks directory. It claims to be version 2.0.0, so I hope that is just an error cuz that will never work.

The bundle plugins directory should be what is searched, so I have no idea how that got screwed up. You would have to post more of the log. Are you actually running it by double-clicking the app, or are you doing it via terminal?

Since you've already gone though the trouble of brew and installing SDL, there isn't anymore effort to building yourself, tho you will want SDL2, not 1.

Information on whether I'm missing any dependencies; info. on how/where to set the SDL path / version.

You don't need any of this unless you want to build. GemRB ships with everything it needs that isn't supplied by macOS.

[lynxlynxlynx]

sdl2_mixer needed to be installed by the user who helped with testing, same as sdl2 (or there was no audio, since the openal backend isn't being built). The bundled libs were not being picked up at all.

[anijatsu]

The odd thing is that the two lines that I’ve posted are the entirety of the log. I’ve been running the application by the usual double-clicking. As I’ve read in other issues, there can be issues with path detection otherwise.

Since you mentioned the application is unsigned, I remembered that post extraction I did have to remove it from system quarantine manually. Otherwise I was getting the “application is broken” error prompting me to remove the file. At the time I thought it to be some sort of network lag, where the system couldn’t check the certificate validity before a timeout. I used the xattr -rd com.apple.quarantine /App/path.app command if I recall correctly.

But also, the OS is already running in Reduced Security Policy. I’m on my mobile, but I’m thinking perhaps the libraries are still somehow being blocked from running?

When I return I’ll check the system console and whether it produces any additional output.

[bradallred]

sdl2_mixer needed to be installed by the user who helped with testing, same as sdl2 (or there was no audio, since the openal backend isn't being built). The bundled libs were not being picked up at all.

The failure here is due to using "unix" libraries, which are going to produce an rpath to the homebrew location. We should add a proper linker flag to change that when producing builds that don't use the normal framework.

Also, OpenAL ships with macOS, so we must be forcefully building against some homebrew version for that to break.

@anijatsu You can fix the linkage by following the steps to change the rpath to the libs inside the app bundle.

[lynxlynxlynx]

OpenAL is explcitly disabled, since there were conflicts with the shipped version that I couldn't resolve.

[bradallred]

thats interesting, since I have never built with anything other than that. I do know it doesn't support the EFX extensions, so maybe thats a good reason to not produce a release with it, but it should still work.

[lynxlynxlynx]

I was just patching things as needed when setting up the build bots; it's too annoying when you don't have access to the hw. In that regard CirrusCI is great, because you can trivially shell into the build image when it fails, investigate and try fixes.

[bradallred]

looks like we need to set CMAKE_MACOS_RPATH, but it seems likely there is something else interfering since that should be the default.

maybe this needs fixing: https://github.com/gemrb/gemrb/blob/af0410fce89a4f46514b06d0aea82e393ccec311/CMakeLists.txt#L191-L196

or this: https://github.com/gemrb/gemrb/blob/af0410fce89a4f46514b06d0aea82e393ccec311/gemrb/CMakeLists.txt#L118

[lynxlynxlynx]

cmake will run the install-name-tool or whatwasit for us. We do have three slightly different use cases now and maybe they're just not all implemented fully or compatibly:

• use cmake as an xcode project generator
• use cmake to build a Frameworks version directly
• use cmake to build a "unix" version directly

[bradallred]

yeah, we should discuss those in #1863

[bradallred]

after b4d8f7a it's likely we just need to remove some of the if (APPLE) stuff above