Showing results for 
Search instead for 
Did you mean: 

"Oculus Spatializer Native" framework contains a mac .framework, but it is broken

Level 5

I can't find the bug reporter anymore. Posting this here and to the "Contact" form.


The "Oculus Spatializer Native" package for the Oculus Audio SDK ( ) contains native libraries for several platforms. One is what appears to be a Intel mac binary at the subpath Lib/mac64/OVRAudio64.framework . Although this is a little surprising since the Oculus headsets do not work on mac, I was glad to see it because we sometimes build our VR application on Mac for testing purposes and being able to test with the Oculus Audio library in our mac builds would be helpful. Unfortunately, this .framework does not work and does not seem to actually be a .framework.


I attempted to link against this framework with both CMake and "make". I got the same error with both. A minimal repro follows. Place in a folder this main.c:



#include <stdio.h>
#include "OVR_Audio.h"

int main() {
ovrAudioContextConfiguration config = {};
config.acc_Size = sizeof( config );
config.acc_SampleRate = 48000;
config.acc_BufferLength = 512;
config.acc_MaxNumSources = 16;
ovrAudioContext context;
if ( ovrAudio_CreateContext( &context, &config ) != ovrSuccess )
printf( "WARNING: Could not create context!\n" );
return 1;

return 0;



and this Makefile:



OVRPATH ?=/Users/mcc/Downloads/spatializers/AudioSDK

CC ?= cc
CFLAGS ?= -I$(OVRPATH)/Include
LDFLAGS ?= -framework $(OVRPATH)/Lib/mac64/OVRAudio64.framework


main: main.o
    $(CC) $(LDFLAGS) main.o -o main


main.o: main.c
    $(CC) $(CFLAGS) -c main.c


    rm -f main main.o



(Obviously you will have to replace OVRPATH to point to a download of the SDK, note there should be no space at the start of the path, and note you will have to manually convert all four-space indents to tabs, this forum software appears to eat tabs.)


Running this example, I get


cc -framework  /Users/mcc/Downloads/spatializers/AudioSDK/Lib/mac64/OVRAudio64.framework main.o

ld: framework not found  /Users/mcc/Downloads/spatializers/AudioSDK/Lib/mac64/OVRAudio64.framework

clang: error: linker command failed with exit code 1 (use -v to see invocation)


The framework is not recognized *as* a framework. Looking, this seems correct, as the documentation for framework bundles indicate a .framework should contain items that are not present in the OVRAudio64.framework, such as symlinks from the base level to the binary. The only files in this framework are OVRAudio64.framework/Versions/A/ovraudio64 and 

OVRAudio64.framework/Versions/A/Resources/Info.plist .


The ovraudio64 file does appear to be a dylib, but it is not a usable one. If I try linking the inner dylib directly, I get:


$ cc -I/Users/mcc/Downloads/spatializers/AudioSDK/Include -c main.c

$ cc /Users/mcc/Downloads/spatializers/AudioSDK/Lib/mac64/OVRAudio64.framework/Versions/A/ovraudio64 main.o -o main

$ ./main

dyld: Library not loaded: /data/sandcastle/boxes/trunk-hg-ovrsource/arvr/libraries/audio/AudioSDK/build/mac64/OVRAudio/ovraudio64.framework/Versions/A/ovraudio64

  Referenced from: /Users/mcc/work/gh/lovr/temp/ovraudio/./main

  Reason: image not found

Abort trap: 6


"/data/sandcastle" appears to be an absolute path on one of your build servers. This dylib will work on that build server, but probably not on any other computer because it expects to be installed at that exact literal path. This indicates the dyld install name is set incorrectly; you can verify this with "otool -L". For a library built as a redistributable framework I would expect the dyld name to use the @rpath or @loader_path special variables which situate it within a framework or built application. It is possible for a developer using ovraudio on mac to fix this manually by using install_name_tool -id on the dylib or install_name_tool -change on the built binary; consider this alternate Makefile:



OVRPATH ?=/Users/mcc/Downloads/spatializers/AudioSDK
CC ?= cc
CFLAGS ?= -I$(OVRPATH)/Include
LDFLAGS ?= ./ovraudio64.dylib

main: main.o ovraudio64.dylib
    $(CC) $(LDFLAGS) main.o -o main -rpath .

main.o: main.c
    $(CC) $(CFLAGS) -c main.c

    cp $(OVRPATH)/Lib/mac64/OVRAudio64.framework/Versions/A/ovraudio64 ovraudio64.dylib
    install_name_tool -id @rpath/ovraudio64.dylib ovraudio64.dylib

    rm -f main main.o ovraudio64.dylib



This will produce a runnable binary, but install_name_tool is pretty arcane so most users would probably not be able to figure this out.


Note: The above tests were done with the command line build tools since I don't have a working XCode on this machine. Just to make sure XCode doesn't behave differently, I asked a friend to test. They tested with macOS 11.2.2 and XCode 12.4. Running with the code from my main.c above and the framework added to the project via [right click Project]->"Add Files", they got the same error I did at the command line, "Framework not found OVRAudio64". This shows XCode is not able to recognize your .framework as a framework. However, when they created a "doctored" ovraudio64.dylib through the steps from the second Makefile above— copy the ovraudio64 dylib out of the .framework directory and run `install_name_tool -id @rpath/ovraudio64.dylib ovraudio64.dylib` on it— they were able to successfully compile and run the project by adding the doctored ovraudio64.dylib to the project using "Add Files" and adding a "Copy to Frameworks" build phase for the ovraudio64.dylib file. (XCode by default builds its applications with an rpath that includes the application bundle frameworks directory.)


"Expected Behavior", if this were a bug report: It's great you're trying to include a mac build, but you should either ship a fully functional .framework or (since you aren't using any .framework features) ship just a dylib and give it a normal dyld install name such as @rpath/ovraudio64.dylib.