Compiling OpenAL `1.23.0` for Android.

Question

Compiling OpenAL `1.23.0` for Android.

Opened this issue 2 years ago · 42 comments

Hello,

I'd like to know how I can (separately) compile OpenAL for Android with an OpenSL-ES or Oboe 'background'.

I'm sorry, but my knowledge of build systems is bleak.

All of my personal attempts ended with me generating a Visual Studio solution, and building that, which would give me DLLs and not Shared Objects.

I have also tried using the CMake commands mentioned in the XCompile-Android.txt file, but they throw errors about my Visual Studio installation not supporting Clang (even after installing the 'toolchain' components for Mobile Development in Visual Studio).

Could you please provide guidance on what I should be doing?

I thank you, in advance.

Answer 1 · 2023-02-21T18:34:09.000Z

You will need to install a compiler toolchain for building code for Android. The Android NDK provides compilers for compiling to Android from other systems. Unfortunately I don't know much about VS's Android support to know how to build a CMake project with it to generate Android binaries.

What exactly did you try to run, and what was the output? Can you paste it here?

Answer 2 · 2023-02-22T02:40:06.000Z

...I guess it's not a good idea to use Visual Studio for this right now.

CMake also seems to prefer to build for Visual Studio for some reason. Wondering if there's an environment variable (or CMake script variable) to fix that.

I get the following output when using CMake (cmake .. -DANDROID_STL=c++_shared -DCMAKE_TOOLCHAIN_FILE=C:\Projects\Android\AAA_LIBS\SDK\ndk\21.4.7075529\build\cmake\android.toolchain.cmake):

-- Building for: Visual Studio 17 2022
-- ANDROID_PLATFORM not set. Defaulting to minimum supported version
16.
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Projects/Android/AAA_LIBS/SDK/ndk/21.4.7075529/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- Check for working C compiler: C:/Projects/Android/AAA_LIBS/SDK/ndk/21.4.7075529/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "C:/Projects/Android/AAA_LIBS/SDK/ndk/21.4.7075529/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/Users/Brahvim/Documents/GitHub/OpenAL_Soft/build/CMakeFiles/CMakeTmp

    Run Build Command(s):C:/Program Files/Microsoft Visual Studio/2022/Community/MSBuild/Current/Bin/amd64/MSBuild.exe cmTC_acf46.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=17.0 /v:m && MSBuild version 17.4.1+9a89d02ff for .NET Framework
      ANDROID_HOME=C:\Program Files (x86)\Android\android-sdk
      ANDROID_SDK_ROOT=C:\Program Files (x86)\Android\android-sdk
      ANT_HOME=
      JAVA_HOME=
      NDK_ROOT=
      testCCompiler.c
    TRACKER : error TRK0005: Failed to locate: "clang.exe". The system cannot find the file specified. [C:\Users\Brahvim\Documents\GitHub\OpenAL_Soft\build\CMakeFiles\CMakeTmp\cmTC_acf46.vcxproj]

Answer 3 · 2023-02-22T04:49:57.000Z

You can try to remove the -DANDROID_STL=c++_shared parameter, let it use the default STL it wants to use and see if that lets it work. If not, does the listed file

C:/Projects/Android/AAA_LIBS/SDK/ndk/21.4.7075529/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe

not exist?

The -G switch can be used to tell CMake to use other generators (availability depending on platform) if you don't want it to use VS. cmake --help shows what generators are available.

Answer 4 · 2023-02-22T14:40:08.000Z

I used CMake-gui to delete CMake's cache and then specified a location for NDK's clang.exe and clang++.exe. Doing so brought me to this screen:

After adding the OPENSL_INCLUDE_DIR (path\to\ndk\21.4.7075529\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\include\SLES),

OPENSL_ANDROID_INCLUDE_DIR (path\to\ndk\21.4.7075529\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\include\SLES), and the

OPENSL_LIBRARY (path\to\ndk\21.4.7075529\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\lib\arm-linux-androideabi\16) entries, and 'turning off' the ALSOFT_BACKEND_* entries, I was able to compile the library, and as expected, the generated programs (such as altonegen.exe do not know what devices are available (because this build had no audio backend?).

Later, I realized I didn't 'turn on' ALSOFT_OPENSL_BACKEND. CMake does not work as expected when that is 'turned on':

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22000.
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
Could NOT find ALSA (missing: ALSA_LIBRARY ALSA_INCLUDE_DIR) 
Could NOT find OSS (missing: OSS_INCLUDE_DIR) 
Could NOT find AudioIO (missing: AUDIOIO_INCLUDE_DIR) 
Could NOT find SoundIO (missing: SOUNDIO_LIBRARY SOUNDIO_INCLUDE_DIR) 
Could NOT find PortAudio (missing: PORTAUDIO_LIBRARY PORTAUDIO_INCLUDE_DIR) 
Could NOT find PulseAudio (missing: PULSEAUDIO_LIBRARY PULSEAUDIO_INCLUDE_DIR) 
Could NOT find JACK (missing: JACK_LIBRARY JACK_INCLUDE_DIR) 
Could NOT find OpenSL (missing: OPENSL_LIBRARY OPENSL_INCLUDE_DIR OPENSL_ANDROID_INCLUDE_DIR) 
CMake Error at CMakeLists.txt:1143 (message):
  Failed to enabled required OpenSL backend.

Since OpenSL is no longer well supported on Android anyway, could you please provide any guidance on how I should go about getting Oboe to work?

Again, thank you very much for your time, in advance!

Answer 5 · 2023-02-22T20:21:50.000Z

Later, I realized I didn't 'turn on' ALSOFT_OPENSL_BACKEND. CMake does not work as expected when that is 'turned on':

The ALSOFT_xxx_BACKEND options just tell CMake to allow the backend, to look for and enable it if found, and disable it if not. The ALSOFT_REQURE_xxx options tell CMake to require the given backend, to fail if its not enabled.

Since OpenSL is no longer well supported on Android anyway, could you please provide any guidance on how I should go about getting Oboe to work?

If you don't already have it, you need to get the Oboe sources. Then set the OBOE_SOURCE option for CMake to the path where its CMakeLists.txt is (e.g. -DOBOE_SOURCE=path/to/oboe, where path/to/oboe/CMakeLists.txt exists for Oboe). OpenAL Soft will then build it as part of its build process and enable the backend to use it.

Answer 6 · 2023-02-25T17:25:19.000Z

Hello there!

Compiling with the OpenSL backend has succeeded! (Resulting in a ~15.7 MB libopenal.so, among others.)
Compiling with Oboe failed. Compiling Oboe was giving me some issues with Oboe itself, which I could go report at the Oboe repository.

Not only did I succeed, I learnt a lot about build systems as well. Thank you very-much for your immeasurably important guidance, sir @kcat!

I'll leave instructions for anyone inexperienced with build systems like me:

Get the source code for OpenAL Soft from a release of your choice (like the one I used here!). ...Yes, you could also just git clone it into a folder, but I felt it was safer to go for a release.
Start up cmake-gui on your computer (Download link!).
After specifying the folder where the contents of the repository reside (folder of unzipped contents / git repository), and the build directory inside of it, press "Configure". Select "Ninja" in the drop-down menu.
Now, we'll fix the error with the configuration CMake may inform you of. Select "Specify toolchain for cross-compiling". CMake should ask you for the location of the "Toolchain file". For this, find android.toolchain.cmake in path/to/sdk/ndk/xyz/build/cmake/, where path/to/sdk is the path to the Android SDK folder, and xyz is any version number for the Android NDK you may have installed. The complete path would look like so:
path/to/sdk/ndk/xyz/build/cmake/android.toolchain.cmake.
Toggle "Advanced" - a checkbox right under the "Where to build the binaries" textbox, once or twice. This should reveal an 'entry', CMAKE_MAKE_PROGRAM. Do not create it yourself using "Add Entry". That fails!

Set the value for this entry to path/to/sdk/cmake/xyz/bin/ninja.exe, where xyz is any version number of your choice installed on your system. Hold onto this path string for a bit in your clipboard - we'll need it soon!

(For the fellow *nix users, this probably would be somewhere in /usr/bin instead. Oh, and an APT package called ninja-build exists. I couldn't find any package/repository lists online for YUM or DNF, but AUR lists a package called just ninja, which shows that ninja should be installed by other packages. Wondering why this didn't come with APT's android-sdk-platform-tools too.)

Click "Configure" again, and now we play the 'waiting game' :)

Make sure to check ALSOFT_REQUIRE_OPENSL or ALSOFT_REQUIRE_OBOE as per your needs (using both is probably not a good idea, though I haven't tested this hypothesis of using both together).
Since @kcat stated during the discussion of this issue that this step is not a necessary, you may optionally uncheck all of the ALSOFT_BACKEND_* options other than the one for OpenSL or Oboe, whichever you wish to use. I did it literally just for a cleaner-looking log from CMake.
If you're using Oboe, search for the OBOE_SOURCE entry. As you can tell, this refers to the directory where you must've stored the Oboe repository on your computer. As @kcat suggested, it should be the directory containing the CMakeLists.txt file.
As per your wish, and also completely optionally, you may specify an ANDROID_STL entry. Oboe needs for this to be c++_shared, I think. The builds I tried using this entry for also failed after I was done with CMake, so I don't know what you can and cannot do with these values. Let's see!

...and with that, all you need to do for the CMake part of this process, is press "Generate", ...and wait!

Open in a terminal, the build directory inside the OpenAL Soft source folder. Remember that path to ninja.exe we used in CMake? It's time to use that. Paste this into your terminal, ...and now again, we wait.

This program, ninja.exe, should be done building by the time you see a line, like [98/98] Linking C executable al* (al* refers to anything executable OpenAL comes with, such as altonegen or alrecord), output into your terminal. For Oboe, there are about a hundred more tasks, and not just 98.

...anyway, that's it! We're done! Enjoy using OpenAL Soft as libopenal.so! (And the other files!)

Answer 7 · 2023-02-25T22:26:06.000Z

Compiling with the OpenSL backend has succeeded! (Resulting in a ~15.7 MB libopenal.so, among others.)

That would be due to compiling with the default RelWithDebInfo setting. Debug info adds quite a bit of data to the binary to aid in debugging. You can use Release mode instead to cut the size down significantly.

Now, we'll fix the error with the configuration CMake may inform you of. Select "Specify toolchain for cross-compiling".

You should select the toolchain for cross-compiling before clicking Configure. The toolchain contains persistent settings for the host and target environment, so if you configure normally, then try to set the toolchain and configure again, it may not work as expected.

If you're using Oboe, click "Add Entry" and add entries for OBOE_INCLUDE_DIR, OBOE_LIBRARY, OBOE_SOURCE and oboe_DIR

Not all of these are needed. OBOE_INCLUDE_DIR and OBOE_LIBRARY are only used if Oboe is prebuilt/preinstalled somewhere and you want to use that. oboe_DIR would be used (presumably by Oboe's own find/config module) to detect OBOE_INCLUDE_DIR and OBOE_LIBRARY, so all three aren't needed together. OBOE_SOURCE will tell OpenAL Soft's CMake script to look in the provided location for Oboe's CMake script, which will then be added as a sub-project that will get built and used automatically during OpenAL Soft's build. If you set OBOE_SOURCE, the others are ignored.

Answer 8 · 2023-02-26T01:06:52.000Z

I built a binary in Release mode and surprisingly it's still 15 MB. Is the debug info actually useful for a consumer? I could cut down on it if it is related to OpenAL Soft only.

Answer 9 · 2023-02-26T01:50:51.000Z

Is the debug info actually useful for a consumer?

Not typically, unless they experience a problem in the library and try to get a backtrace or something. You can also use the strip command to remove excess data from the binary.

Answer 10 · 2023-02-26T03:01:59.000Z

Alright, I think my problem has mostly been solved. I should close this issue now. Thank you very much!

Answer 11 · 2023-04-04T01:45:34.000Z

Hello there! I'm sorry to open this issue again, but there's a problem that I did not mention at all - I did not get a static library (.a).

In order to use shared objects on Android, I need one of those, too.

As far as I can see, the CMake script has no options for this. How do I do this?

Thank you very much in advance!

Answer 12 · 2023-04-04T13:51:44.000Z

Hello there! I'm sorry to open this issue again, but there's a problem that I did not mention at all - I did not get a static library (.a).

In order to use shared objects on Android, I need one of those, too.

Unlike Windows, separate .a files are unnecessary for using shared libraries on Android/Linux/macOS.

Static libraries essentially contain compiled object files (.o files) that are linked with the executable as if they were all built as the same project. Shared libraries (.so files, or .dylib on macOS) stay separate, the linker uses them directly to know what symbols they provide and which are needed at runtime. The two are mutually exclusive; if you use a static library for some library, you don't also use the shared library, and vice-versa.

Answer 13 · 2023-04-04T17:14:13.000Z

Thank you very much for explaining that to me! For the entirety of this issue, I've only been messing up basic terms related to C++ development environments.

I will read up on, and experiment with setting up shared libraries on Android with more effort this time. Will try not to disturb you with this further.

I deeply appreciate your patience. Thank you very much.

Answer 14 · 2023-10-30T18:29:05.000Z

Thank you very much for the guide how to build OpenAL-Soft for Android. As a Dephi developer, I didn't know anythig about CMake and building projects this way. I was able to build libopenal.so following this guide. That's great. However, the resulting library binary is 32bit. Is it possible to build 64bit library also? I have tried to add some CMake entries regarding Android architecture to no vain. I also tried to modify build.ninja file, replacing -march=arm7-a with 64bit equivalents, with no success. A dlopen() call returns an error about 32bit library (since my app is 64bit native).

Answer 15 · 2023-11-03T15:34:45.000Z

I have managed to solve the issue how to build OpenAL-Soft for Android amr64. One needs to add entry (via GUI "Add Entry", or via command line parameter) ANDRIOD_ABI = arm64-v8a, and specifying desired API version via ANDROID_PLATFORM entry. One also needs to modify OPENSL_LIBRARY to point to the aarch64-linux-android folder with desired API version.

Answer 16 · 2023-11-05T02:05:07.000Z

Thank you very much for looking around here, @Centurion96! ...And you even solved your own issue yourself. That's awesome. Thank you very much!

PS Could you please tell me which aarch64-linux-android folder we're talking about here? I haven't looked back at this issue in a while, <gulp>, so I don't have any context either. Thank you, thank you.

Answer 17 · 2023-11-06T10:35:25.000Z

By default, cmake sets OPENSL_LIBRARY to {ndk_version_path}/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/lib/arm-linux-androideabi/21/libOpenSLES.so, where 21 is the default platform version when you didn't specify one.

In order to compile and link for a different architecture and different platform version, the path needs to point to the library file specific for that architecture and that platform version.

For example, if you set ANDRIOD_ABI = arm64-v8a and ANDROID_PLATFORM = 25 then you need to modify OPENSL_LIBRARY path in the following way:
{ndk_version_path}/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/lib/aarch64-linux-android/25/libOpenSLES.so

Answer 18 · 2024-02-07T11:40:08.000Z

I have managed to solve the issue how to build OpenAL-Soft for Android amr64. One needs to add entry (via GUI "Add Entry", or via command line parameter) ANDRIOD_ABI = arm64-v8a, and specifying desired API version via ANDROID_PLATFORM entry. One also needs to modify OPENSL_LIBRARY to point to the aarch64-linux-android folder with desired API version.

@Centurion96 Nicely done. Would you mind sharing your compiled libopenal.so? Also I wonder if we could add android compilation to GitHub actions 🤔

I recently found that there's an android build of sView which should've been able to virtualize surround and spatialize ambisonics, but the library is too old so I'm hoping replacing it (rooted) fixes the issue like on Windows so that I can confirm this is what the dev needs to do to fix this.

Answer 19 · 2024-02-07T12:53:21.000Z

Android.arm64-v8a.zip
This is a compiled OpenAL Soft 1.23.1 for Android Arm64 with OpenSL backend.

Answer 20 · 2024-02-07T14:28:47.000Z

Android.arm64-v8a.zip This is a compiled OpenAL Soft 1.23.1 for Android Arm64 with OpenSL backend.

Dang it, App Manager lied to me.. That's why I thought "armeabi-v7a" here was just outdated, but apparently the library's actually 32-bit?

so would you or @Brahvim happen to have a somewhat recent armeabi-v7a libopenal.so handy? 👀
I managed to compile sView for Android and also found where it pulls dependencies from so I might be able to put together a PR to save the dev some work

Answer 21 · 2024-02-07T16:44:13.000Z

Android.armeabi-v7a.zip
This is a compiled OpenAL Soft 1.23.1 for Android 32bit arm + neon with OpenSL backend.

Answer 22 · 2024-02-07T17:50:18.000Z

Android.armeabi-v7a.zip
This is a compiled OpenAL Soft 1.23.1 for Android 32bit arm + neon with OpenSL backend.

Thanks so much mate! Now the app started and loaded the DLL properly
Though now i just gotta figure out why it's not respecting the HRTF settings 🤔

The dev is probably gonna have to look at the code to see why the settings aren't sticking, but in the meantime, the log tells me where it expects the config file and even MHRs, so hopefully it'll allow me to use my HRTF 🤞

Answer 23 · 2024-02-09T10:19:57.000Z

Android.arm64-v8a.zip This is a compiled OpenAL Soft 1.23.1 for Android Arm64 with OpenSL backend.

AYY! Congrats to everybody here. We finally figured it out! 😂
It's great to see this! I'll be compiling OpenAL for my armeabi-v8 device, probably.

...Wait, this binary is called "Android.arm64-v8a.zip"?
...Oh. Okay... Anyway:
So... can I use this via the JNI with a CMake script now...? (I don't know much about native development on Android or build systems just like back in the day, sorry!)

Thank you very much for answering :)
And yet again - congrats! To everybody here! ":D!

Answer 24 · 2024-02-11T16:42:03.000Z

@Centurion96 So I figured out the issue with HRTF in sView (and potentially other OpenAL apps on Android) and explained it here.
But tl;dr, updating the library was just one part of the puzzle. The other part is getting it to load an MHR, which it currently lacks since it's not embedded and apparently it's attempting to use Linux paths that either don't exist or are root-restricted on Android.

So sorry to bother you again but do you think it would be possible to embed Default HRTF.mhr into libopenal.so like how it's loaded from OpenAL32.dll on Windows? If you do get a chance to take a stab at it, perhaps it might also be useful to compile with Release configuration to reduce the filesize 👀👌

Answer 25 · 2024-02-11T17:07:57.000Z

Should we ask kcat?

Answer 26 · 2024-02-11T17:45:18.000Z

After a bit more digging I found he already mentioned a way to do it here #46 (comment)
So I guess what we need is compile with -DALSOFT_EMBED_HRTF_DATA=TRUE though I agree with #46 (comment) that it'd be better to also have an external, easily-accessible folder to load custom MHRs and I'm not sure if there's a flag for that we don't have to copy an alsoft.config with external hrtf-paths set into a system folder that requires root access.
So @kcat what would you recommend?

Answer 27 · 2024-02-11T18:01:24.000Z

Should we ask kcat?

The default HRTF is embedded by default (ALSOFT_EMBED_HRTF_DATA is true be default), a build has to explicitly disable it when configuring with cmake to exclude it. Which some people may do because they don't want to use HRTF (they don't like it, or it's too resource-intensive), or they don't want to increase the file size of the library (by about ~157KB).

As for specifying extra folders for custom MHRs, you can either set the ALSOFT_LOCAL_PATH environment variable to a path where it can find .mhr files, or add an extra path to the XDG_DATA_DIRS environment variable where it will look for <path>/openal/hrtf/*.mhr files. If there are extra paths Android systems would prefer to look in for application data by default (aside from the XDG specified paths, and the current working directory), I can consider adding them to OpenAL Soft.

Answer 28 · 2024-02-11T20:57:17.000Z

@kcat In that case I can look into setting up an Android build workflow so I don't have to keep botherin Centurion96 😅
Also, it seems like specifying external paths on OpenAL Soft's end won't cut it, because apparently recent Android limits the locations apps can access (thanks, ~~Obama~~ Scoped storage.)

So it fails to find the MHR copied to most folders set in hrtf-paths:

❌/storage/self/primary/Download

❌/storage/self/primary/openal/hrtf

✅/storage/self/primary/Android/data/com.sview/openal/hrtf

However, the problem with using the app's data folder is that users without root won't be able to copy anything to it.

On the bright side, I think that if the app creates a public folder in the internal storage, it might allow other apps to read and write to it. So do you think it might be possible to make OpenAL Soft create /storage/self/primary/openal/hrtf on its own?
Otherwise, I guess it'd require modifying the app's behavior to create its own folder, request to access a user-created folder or even use special permissions to have more access to user-created folders. 🤔
To be honest, I'm not particularly experienced in Android programming so I'm just spitballing here lol

Answer 29 · 2024-02-12T03:08:34.000Z

It doesn't sound like a good idea for OpenAL Soft to create publicly accessible directories on the app. That should be up to the app itself to do if it wants.

Answer 30 · 2024-02-12T11:11:52.000Z

@kcat Fair enough, so the only reasonable, non-root alternative I can think of is for the app to add a scoped storage folder picker dialog for the user to explicitly allow the app to access a specific, public folder containing HRTF/*.mhr and probably alsoft.conf and instructing OpenAL Soft to use it (by adding it to XDG_DATA_DIRS and XDG_CONFIG_DIRS, respectively, I presume)
Would that work? 🤔

Answer 31 · 2024-02-12T16:53:13.000Z

Pretty much. The app would set the ALSOFT_LOCAL_PATH env var with setenv to the path it provides for the user to add mhr files (where it will look in the given path directly, no subdirs). Or append a path to XDG_DATA_DIRS where OpenAL Soft will then look in <path>/openal/hrtf/ for more mhr files.

Similarly, it can prepend a path to XDG_CONFIG_DIRS where it will look for <path>/alsoft.conf. This needs to be done before making any OpenAL calls, since OpenAL Soft will initialize and load the config settings on certain calls, and won't reload the configs afterward.

Answer 32 · 2024-09-13T08:38:26.000Z

So I've been following this and have been able to compile the libopenal.so file with oboe, however when I try to include it into my C# avalonia project, it just throws a bunch of dependency errors, first it was missing libstdc++.so.6 so I found it in the android NDK files and included it, second it was missing libm.so.6 so I also included that from the NDK, and now this. I have absolutely no idea what is going on.

Answer 33 · 2024-09-13T10:22:45.000Z

OpenAL Soft uses C++, so it needs the C++ runtime (libstdc++ or libc++ depending on the compiler/system). libm is a library some compilers put math functions in. libgcc_s is a library that GCC uses for various GCC-related functions. You can set ALSOFT_STATIC_LIBGCC and/or ALSOFT_STATIC_STDCXX with CMake to static-link libgcc_s and libstdc++ if having the extra libs is a problem (they'll be linked directly into libopenal, increasing the filesize but not requiring those two libs). If anything else in your project needs libgcc_s or libstdc++ though, it would be best to not static-link them as you'd just end up with multiple copies.

You'd still need to include libm though.

Answer 34 · 2024-09-13T10:26:08.000Z

OpenAL Soft uses C++, so it needs the C++ runtime (libstdc++ or libc++ depending on the compiler/system). libm is a library some compilers put math functions in. libgcc_s is a library that GCC uses for various GCC-related functions. You can set ALSOFT_STATIC_LIBGCC and/or ALSOFT_STATIC_STDCXX with CMake to static-link libgcc_s and libstdc++ if having the extra libs is a problem (they'll be linked directly into libopenal, increasing the filesize but not requiring those two libs). If anything else in your project needs libgcc_s or libstdc++ though, it would be best to not static-link them as you'd just end up with multiple copies.

You'd still need to include libm though.

I'll try that. Thank you!

Answer 35 · 2024-09-13T11:26:19.000Z

Ok. so I tried compiling with both STATIC variables set to true and this error came up.

Answer 36 · 2024-09-13T23:00:25.000Z

I tried using the android-ndk-r21e and that still failed to compile with the following error.
libcommon.a: error adding symbols: Archive has no index; run ranlib to add one clang++: error: linker command failed with exit code 1 (use -v to see invocation)

ANDROID_ABI was set to arm64-v8a and the ANDROID_PLATFORM was set to 24 with OBOE enabled and pointing to source.

Answer 37 · 2024-09-14T07:20:16.000Z

I'm honestly a bit confused. You appear to be building on Windows targeting Android/ARM, using Clang, but ends up needing libgcc_s and libstdc++, which are there for linking but not available at runtime. If they aren't implicitly available on the system for some reason, including the libs with the app's package should be enough. I've not seen errors like that when I build for Android, either.

Answer 38 · 2024-09-14T09:42:55.000Z

So after a lot of messing around. I was able to get somewhere without it completely breaking, the unfortunate thing is it's hitting the max error limit which I tried to disable by passing in the CXX and C flags with -ferror-limit=0 but that didn't work, here is the error limit I am getting.

ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
CLANG_~1: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Answer 39 · 2024-09-17T06:19:50.000Z

Ok. I was able to compile OpenAL 1.23.1 with android NDK r27b without any modifications except for setting ANDROID_ABI to arm64-v8a and ALSOFT_STATIC_LIBGCC set to true with OPENSL_LIBRARY set to the correct libOpenSLES.so. However, loading the library still throws libgcc_s.so.6 was not found even though it was statically linked (as said above). I don't know if its just a me problem missing some installed CXX compilers or the framework I am using which is a C# program using monodroid as the backend.

Is there a way I can provide libgcc_s.so as it's own file because I cannot find it as part of the android NDK.

Answer 40 · 2024-09-17T17:33:54.000Z

I honestly have no idea why there would be a dependency on libgcc_s if you're building with Clang. Can you try building OpenAL Soft for Android with a fresh/empty build directory and paste the output of CMake?

Answer 41 · 2024-09-17T23:20:29.000Z

CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

ANDROID_PLATFORM not set. Defaulting to minimum supported version
21.
The C compiler identification is Clang 18.0.2
The CXX compiler identification is Clang 18.0.2
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working C compiler: C:/Users/flyin/Downloads/OpenAL/android-ndk-r27b/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe - skipped
Detecting C compile features
Detecting C compile features - done
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Check for working CXX compiler: C:/Users/flyin/Downloads/OpenAL/android-ndk-r27b/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe - skipped
Detecting CXX compile features
Detecting CXX compile features - done
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Looking for posix_memalign
Looking for posix_memalign - found
Performing Test HAVE___RESTRICT
Performing Test HAVE___RESTRICT - Success
Performing Test HAVE_LIBATOMIC
Performing Test HAVE_LIBATOMIC - Success
Looking for __android_log_print in log
Looking for __android_log_print in log - found
Performing Test HAVE_WNO_CXX20_ATTR_EXT
Performing Test HAVE_WNO_CXX20_ATTR_EXT - Success
Performing Test HAVE_FNO_MATH_ERRNO
Performing Test HAVE_FNO_MATH_ERRNO - Success
Performing Test HAVE_GCC_PROTECTED_VISIBILITY
Performing Test HAVE_GCC_PROTECTED_VISIBILITY - Success
Performing Test HAVE_MSSE2_SWITCH
Performing Test HAVE_MSSE2_SWITCH - Failed
Looking for xmmintrin.h
Looking for xmmintrin.h - not found
Looking for emmintrin.h
Looking for emmintrin.h - not found
Looking for pmmintrin.h
Looking for pmmintrin.h - not found
Looking for smmintrin.h
Looking for smmintrin.h - not found
Looking for arm_neon.h
Looking for arm_neon.h - found
Performing Test HAVE_NEON_INTRINSICS
Performing Test HAVE_NEON_INTRINSICS - Success
Looking for malloc.h
Looking for malloc.h - found
Looking for cpuid.h
Looking for cpuid.h - not found
Looking for intrin.h
Looking for intrin.h - not found
Looking for guiddef.h
Looking for guiddef.h - not found
Looking for initguid.h
Looking for initguid.h - not found
Looking for pow in m
Looking for pow in m - found
Looking for clock_gettime in rt
Looking for clock_gettime in rt - not found
Looking for dlfcn.h
Looking for dlfcn.h - found
Looking for dlopen in dl
Looking for dlopen in dl - found
Looking for posix_memalign
Looking for posix_memalign - found
Looking for _aligned_malloc
Looking for _aligned_malloc - not found
Looking for proc_pidpath
Looking for proc_pidpath - not found
Looking for pthread.h
Looking for pthread.h - found
Performing Test HAVE_PTHREAD
Performing Test HAVE_PTHREAD - Success
Looking for pthread_setschedparam
Looking for pthread_setschedparam - found
Looking for include files pthread.h, pthread_np.h
Looking for include files pthread.h, pthread_np.h - not found
Looking for pthread_setname_np
Looking for pthread_setname_np - found
Looking for getopt
Looking for getopt - found
Could NOT find PulseAudio (missing: PULSEAUDIO_LIBRARY PULSEAUDIO_INCLUDE_DIR)
Could NOT find ALSA (missing: ALSA_LIBRARY ALSA_INCLUDE_DIR)
Could NOT find OSS (missing: OSS_INCLUDE_DIR)
Could NOT find AudioIO (missing: AUDIOIO_INCLUDE_DIR)
Could NOT find SoundIO (missing: SOUNDIO_LIBRARY SOUNDIO_INCLUDE_DIR)
Could NOT find JACK (missing: JACK_LIBRARY JACK_INCLUDE_DIR)
Could NOT find oboe (missing: oboe_DIR)
Could NOT find Oboe (missing: OBOE_LIBRARY OBOE_INCLUDE_DIR)
Found OpenSL: C:/Users/flyin/Downloads/OpenAL/android-ndk-r27b/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/lib/arm-linux-androideabi/21/libOpenSLES.so
Could NOT find PortAudio (missing: PORTAUDIO_LIBRARY PORTAUDIO_INCLUDE_DIR)
Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.44.0.windows.1")
Found ZLIB: C:/Users/flyin/Downloads/OpenAL/android-ndk-r27b/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/lib/arm-linux-androideabi/21/libz.so (found version "1.3.0.1")
Could NOT find MySOFA (missing: MYSOFA_LIBRARY MYSOFA_INCLUDE_DIR)
Could NOT find Qt5Widgets
Could NOT find SndFile (missing: SNDFILE_LIBRARY SNDFILE_INCLUDE_DIR)

Building OpenAL with support for the following backends:
OpenSL, WaveFile, Null

Building with support for CPU extensions:
Default, Neon

Embedding HRTF datasets

Installing library and headers
Installing sample configuration
Installing HRTF data files
Installing AmbDec presets

Building utility programs

Building example programs

Configuring done (18.3s)

Answer 42 · 2024-09-22T23:32:56.000Z

I don't know, I've basically given up at this point, I'm just going to use a DSP library and write my own native audio handlers for all the different platforms. Thanks for trying to help me.