-
Notifications
You must be signed in to change notification settings - Fork 545
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
ALSOFT_DLOPEN=ON ALSOFT_REQUIRE_OPENSL=ON builds not working at runtime inside Termux on random Android devices #1111
Comments
I have discovered that, on the affected devices, one possible application-side alternative workaround is to add the argument clang openal-soft_test.c -o openal-soft_test \
-I openal-soft_installation/include \
-L openal-soft_installation/lib \
-lopenal -Wl,--no-as-needed,-lOpenSLES,--as-needed that causes the openal-soft/common/dynload.cpp Line 29 in c14554f
however, this does not explain why it is only necessary on some devices and not other devices, and it also would require remembering to specify that linker argument with every application that is linked against |
I'm curious what the error actually is. If void *handle{dlopen(name, RTLD_NOW)};
const char *err{dlerror()};
if(err)
{
fprintf(stderr, "%s\n", name, err);
handle = nullptr;
} |
Thank you for the good suggestion, I have added that into the reproduction script like this: reproduction script with improved loggingyes | pkg upgrade -y
pkg install -y build-essential git
rm -rf openal-soft_*
git clone https://github.com/kcat/openal-soft.git openal-soft_src
git -C openal-soft_src apply -v --whitespace=fix << EOF
--- a/common/dynload.cpp
+++ b/common/dynload.cpp
@@ -22,13 +22,17 @@ void *GetSymbol(void *handle, const char *name)
#elif defined(HAVE_DLFCN_H)
#include <dlfcn.h>
+#include <stdio.h>
void *LoadLib(const char *name)
{
dlerror();
void *handle{dlopen(name, RTLD_NOW)};
const char *err{dlerror()};
- if(err) handle = nullptr;
+ if(err) {
+ fprintf(stderr, "dlopen(\"%s\") failed: %s\n", name, err);
+ handle = nullptr;
+ }
return handle;
}
void CloseLib(void *handle)
EOF
cmake -S openal-soft_src -B openal-soft_build \
-DCMAKE_INSTALL_PREFIX=$(pwd)/openal-soft_installation \
-DALSOFT_UTILS=OFF \
-DALSOFT_EXAMPLES=OFF \
-DALSOFT_TESTS=OFF \
-DALSOFT_REQUIRE_OPENSL=ON \
-DOPENSL_LIBRARY=/system/lib$(uname -m | grep 64 > /dev/null && echo '64' || echo '')/libOpenSLES.so \
-DALSOFT_DLOPEN=ON
cmake --build openal-soft_build
cmake --install openal-soft_build
cat > openal-soft_test.c << EOF
#include <stdio.h>
#include "AL/al.h"
#include "AL/alc.h"
#include "AL/alext.h"
int main(void) {
ALCdevice *device = alcOpenDevice(NULL);
if (device) {
printf("success!\n");
alcCloseDevice(device);
return 0;
}
printf("failure!\n");
return 1;
}
EOF
clang openal-soft_test.c -o openal-soft_test \
-I openal-soft_installation/include \
-L openal-soft_installation/lib \
-lopenal
export ALSOFT_LOGLEVEL=3 LD_LIBRARY_PATH=openal-soft_installation/lib/
./openal-soft_test Using this, I have been able to observe the string that is stored into It sort of makes sense this would be the case, but this reveals that the error message is slightly different on at least one of the affected devices, confirming that subtle, possibly unpredictable differences between the
|
I'm not sure what I can do here. It seems to be an issue with libOpenSLES.so/Android that the lib requires something that's not available. I don't know why linking with |
I am sorry for the delay in response, I suspect that it might be possible to carefully construct a crafted test case that would also cause the and I believe that the Termux app but it is just taking a long time to set up those things, and doing so will make it somewhat obvious that the crafted test case deviates so far from the environments that the creators of I believe that the major difference between environments where the problem is reproducible (on affected devices), and environments where it is not (on any devices), is that environments where the problem is not reproducible usually involve a large application with a main ELF and that environments where the problem is reproducible usually involve a very minimal ELF file that has very few dependencies other than openal-soft itself, and which has been compiled using an Android toolchain in such a way that only the bare minimum of "lower-level" OS libraries in That second type of binary, the type that is only dynamically linked to the very minimal set of "lower-level" OS libraries and then also to I will update this further once I complete one of those two goals I mentioned at the start of this comment. The Termux app maintainers have accepted |
Hi I am sorry that this is such an obscure edge case to the point that I don't know whether this is actually a supported use case of openal-soft or not, I just don't know where else to ask if anyone has knowledge of what is happening, because this happens to openal-soft builds cloned from this repository and compiled manually inside Termux as well as to the openal-soft build that comes from
pkg install openal-soft
. If it only happened to the openal-soft build that comes frompkg install openal-soft
then I would not open an issue here, but it is also happening to openal-soft fromgit clone https://github.com/kcat/openal-soft.git
inside of Termux apps, so I thought that you might know what is causing this to happen.Terminal emulator app: https://f-droid.org/en/packages/com.termux/
Bisection commit: 8767fdd
Devices affected so far that the issue is reproducible on:
Devices not affected so far that the issue is not reproducible on:
commands that reproduce the problem on the affected devices
output of commands that reproduce the problem on affected devices
commands that work around the problem
output of commands that work around the problem
The only difference between these two scripts is that when
-DALSOFT_DLOPEN=ON
is used (or-DALSOFT_DLOPEN
is not specified), then the OpenSLES backend does not work on the affected devices, but when-DALSOFT_DLOPEN=OFF
is used, it does work.The text was updated successfully, but these errors were encountered: