internal/graphicsdriver/metal: failed to load .framework files

[lowfatcode]

Ebitengine Version

v2.5.7

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• Xbox
• Web Browsers

Go Version (go version)

1.21.0

What steps will reproduce the problem?

• Upgrade to MacOS Sonoma beta
• clone latest ebiten reposity
• run the blur example with go run .

What is the expected result?

The example should start up.

What happens instead?

The following error is returned:

2023/08/25 20:30:44 ui: failed to choose graphics drivers: Metal: metal: mtl.CreateSystemDefaultDevice failed, OpenGL: gl: failed to load: OpenGL.framework: dlopen(OpenGL.framework/OpenGL, 0x0009): tried: 'OpenGL.framework/OpenGL' (no such file), '/System/Volumes/Preboot/Cryptexes/OSOpenGL.framework/OpenGL' (no such file), '/usr/lib/OpenGL.framework/OpenGL' (no such file, not in dyld cache), 'OpenGL.framework/OpenGL' (no such file), OpenGLES.framework: dlopen(OpenGLES.framework/OpenGLES, 0x0009): tried: 'OpenGLES.framework/OpenGLES' (no such file), '/System/Volumes/Preboot/Cryptexes/OSOpenGLES.framework/OpenGLES' (no such file), '/usr/lib/OpenGLES.framework/OpenGLES' (no such file, not in dyld cache), 'OpenGLES.framework/OpenGLES' (no such file)
exit status 1

Anything else you feel useful to add?

It seems like the purego library that appears to be used to dynamically load libraries is not checking the right path. I think it should be looking in /System/Library/Frameworks/OpenGL.framework.

Perhaps this is a change introduced in Sonoma?

[hajimehoshi]

That's interesting. I'll take a look. Thanks,

CC @TotallyGamerJet just in case.

[hajimehoshi]

@lowfatcode Could you try:

cd /your/cloned/ebiten/path
git fetch origin
git switch issue-2732-exp
go run ./examples/blur

? Thanks,

[lowfatcode]

Yep, that's fixed it!

[hajimehoshi]

Thank you!

[hajimehoshi]

Note that Oto should not have this issue as Oto already uses full paths.

[hajimehoshi]

@lowfatcode By the way, have you set environment variables like DYLD_FALLBACK_FRAMEWORK_PATH?

echo $DYLD_LIBRARY_PATH
echo $DYLD_FALLBACK_LIBRARY_PATH
echo $DYLD_FRAMEWORK_PATH
echo $DYLD_FALLBACK_FRAMEWORK_PATH
env | grep DYDL

Thanks,

[hajimehoshi]

Friendly ping

[hajimehoshi]

I could reproduce the issue with macOS 13.5 Ventura:

$ go build ./examples/blocks/
$ env DYLD_FALLBACK_FRAMEWORK_PATH= ./blocks
2023/08/27 22:22:46 ui: failed to choose graphics drivers: Metal: metal: mtl.CreateSystemDefaultDevice failed, OpenGL: gl: failed to load: OpenGL.framework: dlopen(OpenGL.framework/OpenGL, 0x0009): tried: 'OpenGL.framework/OpenGL' (no such file), '/System/Volumes/Preboot/Cryptexes/OSOpenGL.framework/OpenGL' (no such file), '/usr/lib/OpenGL.framework/OpenGL' (no such file, not in dyld cache), 'OpenGL.framework/OpenGL' (no such file), '/OpenGL.framework/OpenGL' (no such file), OpenGLES.framework: dlopen(OpenGLES.framework/OpenGLES, 0x0009): tried: 'OpenGLES.framework/OpenGLES' (no such file), '/System/Volumes/Preboot/Cryptexes/OSOpenGLES.framework/OpenGLES' (no such file), '/usr/lib/OpenGLES.framework/OpenGLES' (no such file, not in dyld cache), 'OpenGLES.framework/OpenGLES' (no such file), '/OpenGLES.framework/OpenGLES' (no such file)

Setting the environment variable causes this issue, even without a value.

[lowfatcode]

@lowfatcode By the way, have you set environment variables like DYLD_FALLBACK_FRAMEWORK_PATH?

echo $DYLD_LIBRARY_PATH
echo $DYLD_FALLBACK_LIBRARY_PATH
echo $DYLD_FRAMEWORK_PATH
echo $DYLD_FALLBACK_FRAMEWORK_PATH
env | grep DYDL

I haven't set any of those but I think the title of the Issue has been edited by someone else - I never referred to these in my original submission?

[hajimehoshi]

I haven't set any of those but I think the title of the Issue has been edited by someone else

I changed it. I thought this issue was by environment varialbes, rather than macOS 14.

If this happens without setting these environment variables, this might be a bug of macOS 14. Since macOS 14 is still a beta, I was not 100% confident I should back-port the fix to the stable branch.

As I found the same problem could happen with modifying environment variables with macOS 13, I 'generalized' this issue.

[hajimehoshi]

Thank you for confirming the environment variables. My current guess is that macOS 14 beta has some bugs, but the latest commit already includes the fix for the 'generalized' issue (not only for macOS 14 but also macOS 13 with setting environment variables).

[lowfatcode]

Aha! No, I hadn't changed any environment variables.

[hajimehoshi]

Sure! Thank you for reporting this issue again. I appreciate your feedbacks!

[hajimehoshi]

Note to myself: even not setting DYLD_FALLBACK_FRAMEWORK_PATH, this issue happened with Xcode 15... Sigh