Static linking with Oboe 1.9.0 causes OpenSL to crash

[dk-3cx]

Oboe version: 1.9.0
Doesn't reproduce in 1.8.1

The recent change in src/opensles/EngineOpenSLES.cpp included into Oboe 1.9.0 has introduced stubs for OpenSL ES global constants inside the Oboe library and initializes them all with nullptr:

// Satisfy extern in OpenSLES.h
// These are required because of b/337360630, which was causing
// Oboe to have link failures if libOpenSLES.so was not available.
SL_API const SLInterfaceID SL_IID_ENGINE = nullptr;
SL_API const SLInterfaceID SL_IID_ANDROIDSIMPLEBUFFERQUEUE = nullptr;
SL_API const SLInterfaceID SL_IID_ANDROIDCONFIGURATION = nullptr;
SL_API const SLInterfaceID SL_IID_RECORD = nullptr;
SL_API const SLInterfaceID SL_IID_BUFFERQUEUE = nullptr;
SL_API const SLInterfaceID SL_IID_VOLUME = nullptr;
SL_API const SLInterfaceID SL_IID_PLAY = nullptr;

We develop an Android app (in Kotlin) with a native library for it that uses both Oboe and OpenSL. OpenSL is used NOT as a backend for Oboe, but independently from Oboe. Oboe is statically linked with our native lib, while libOpenSLES.so is used as a shared library. This leads to crashes due to null pointer exceptions, because the stubs in Oboe hide the original constants from libOpenSLES.so.

Could you please fix it in some way, e.g. by introducing some #ifdef with a macro that can be passed to cmake when building Oboe? So that we can choose during the compilation if we need these stubs or not.

[philburk]

Hmm. We did not anticipate that.
I try to avoid conditional compilation tricks.
I think it might work if I change SL_IID_ENGINE to OBOE_SL_IID_ENGINE, etcetera.

@dk-3cx - Do you think that would be enough to avoid the naming collisions?

[dk-3cx]

Our code works fine if I remove all the mentioned constants. Renaming them seems to have the same effect. But is such a solution acceptable from your side? I guess you named them this way for a reason, no? (to satisfy some extern declarations)