cmake error with libaom test file

[Artim96]

I managed to set everything up as far as I can see, but after downloading the sources for all libraries the script tries to compile some test file from libaom with gmake, which fails. But to me the error looks strange as it seems to do something with a file that's not existing and it doesn't really look like it's supposed to exist.

Building the component: libaom
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /home/user/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- Check for working C compiler: /home/user/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang - broken
CMake Error at /home/user/Android/Sdk/cmake/3.22.1/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/home/user/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_3a441/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_3a441.dir/build.make CMakeFiles/cmTC_3a441.dir/build
    gmake[1]: entering directory „/home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeTmp“ 
    Building C object CMakeFiles/cmTC_3a441.dir/testCCompiler.c.o
    /home/user/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang   -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security   -o CMakeFiles/cmTC_3a441.dir/testCCompiler.c.o -c /home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeTmp/testCCompiler.c
    /home/user/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin/clang: 1: Syntax error: word unexpected (expecting ")")
    gmake[1]: *** [CMakeFiles/cmTC_3a441.dir/build.make:78: CMakeFiles/cmTC_3a441.dir/testCCompiler.c.o] Fehler 2
    gmake[1]: exiting directory „/home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeTmp“
    gmake: *** [Makefile:127: cmTC_3a441/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:28 (project)

-- Configuring incomplete, errors occurred!
See also "/home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeOutput.log".
See also "/home/user/ffmpeg-android-maker/sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeError.log".
make: *** No destinations given and no „make“-control file found.  End.
make: *** No rule to create „install“ .  End.

Ok, so it's going into the (empty) directory sources/libaom/v3.6.0/aom_build_arm64-v8a/CMakeFiles/CMakeTmp and tries to apply gmake to the file Makefile...this doesn't make much sense. Something's missing, either something that creates that Makefile or the directory of the Makefile is missing.

I just cloned this Git today and I already emptied the sources directory, but without any success either. What's going wrong?

I'm running on Debian testing, SDK v34 and NDK v25 have been installed via Android Studio

[Javernaut]

I've just executed the script as ./ffmpeg-android-maker.sh -abis=arm -aom at current master branch and the very beginning of libaom assembling looks like this:

Building the component: libaom
-- The C compiler identification is Clang 14.0.7
-- The CXX compiler identification is Clang 14.0.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

So my guess is that you didn't set the environment variables properly. Are you able to successfully execute a cd /home/user/Android/Sdk/ndk/25.2.9519653 command?

[Artim96]

doesn't seem to be a problem:

find Android -name "make"
Android/Sdk/ndk/25.2.9519653/prebuilt/linux-x86_64/bin/make

find Android -name "cmake"
Android/Sdk/cmake
Android/Sdk/cmake/3.22.1/bin/cmake
Android/Sdk/cmake/3.22.1/share/bash-completion/completions/cmake
Android/Sdk/emulator/lib/cmake
Android/Sdk/ndk/25.2.9519653/build/cmake
Android/Sdk/ndk/25.2.9519653/sources/cxx-stl/llvm-libc++abi/cmake
Android/Sdk/ndk/25.2.9519653/sources/third_party/googletest/cmake

echo $ANDROID_NDK_HOME
/home/user/Android/Sdk/ndk/25.2.9519653

echo $ANDROID_SDK_HOME
/home/user/Android/Sdk

cd ${ANDROID_NDK_HOME}
~/Android/Sdk/ndk/25.2.9519653

I'm also getting the same error when trying to compile just with aom enabled, like in your example.

[Javernaut]

What exact OS and its version do you use?

[Artim96]

Like I said, Debian Testing. That means I'm currently running what will be Debian 12 by mid-year.

[Javernaut]

So, I've just tested the Debian 11.6, available through WSL2 on Windows 11. I doubt the Testing version can be the cause, but who knows. Long story short: everything works.

After the fresh installation I executed just a handful of commands very similar to how Dockerfile sets the environment. The only significant excepiton: I installed openjdk 11 instead of 8.

If you really set the env variables correctly, then maybe installing the same software will do the thing for you. This is my first experience with Debian specifically, but it is a successful experience.

Despite I download the Android SDK not via the Android Studio, your approach should also work. On my macos machine I use the SDK installed exactly via the Android Studio.

If it still doesn't work, then please look for some log files in libaom directory that can cast some light here.

[Javernaut]

Just to check. Do you use x86 or arm version of Debian?

[Artim96]

Just to check. Do you use x86 or arm version of Debian?

x86 in WSL (1) on Windows 10.

I actually have openjdk-11 and 17 jre installed. Additionally the cmake version from the SDK is 3.22.1-g37088a8 (3.25.1 is installed system wide), meson 1.0.0 (1.0.1 like in the Docker file is only available in sid, so it's questionable if it will even be included in Debian 12, openjdk-17-jdk-headless (no lower version is available), python3 3.11.1. The rest is installed as usual too.

Output of the CMakeError.log and CMakeOutput.log of libaom is attached, but it just looks like more of what I already posted. CMakeOutput.log CMakeError.log

I did previously try to install SDK and NDK in different manners to waste less storage, but I couldn't figure out how to add cmake to those installations. Debian has packages for both that basically just download them from Googles repositories and install them, but it almost looks like Google removed cmake from them and they have not been adapted to them. At least I can't make out any additional packages that adds it.

The command I used is ./ffmpeg-android-maker.sh --target-abis=arm64 --android-api-level=33 --enable-libaom --enable-libdav1d --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopus --enable-libspeex --enable-libvpx --enable-libwebp --enable-libx264 --enable-libfdk-aac

[Javernaut]

I tried setting WSL version to 1 and the script still does work (on Windows 11 though).

JDK version is relevant for Android SDK’s sdkmanager program to work properly. With it you can install the NDK and CMake. The ffmpeg-android-maker relies on CMake inside the Android SDK. Meson and Python are irrelevant for libaom as I remember.

Your logs indeed show only a single error:

Syntax error: word unexpected (expecting ")")

I have never faced such an error on any OS. The Internet says it could happen because of some characters in your PATH variable. I’m not sure if this is a good lead.

The --enable-libfdk-aac flag is ignored. The ffmpeg-android-maker supports only a subset of FFmpeg’s supported libraries and not libfdk-aac at the moment.

Windows was never my primary OS for development. I consider its support for ffmpeg-android-maker as a pet project for a pet project. From my point of view the script does work on Windows with WSL both 1 and 2 in both Ubuntu and Debian. I just followed the same environment setup as in the Dockerfile (which itself configures the Ubuntu env and Ubuntu is based on Debian if my memory serves).

I’m afraid I can’t devote enough time for solving the problem I can’t even reproduce.

I would suggest using the Docker that would eliminate all env setup problems for you. Except for Docker setup itself.

[Artim96]

I think it would help if compiling that file (CMakeCCompilerId.c) could be skipped to see if it can compile anything else. But I have no idea where is is referenced and I can't tell what the actual command is that fails to test it with some really basic c code to see if the compiler is just borked.

[Javernaut]

In my opinion trying to skip a part of the building process of the 3rd party library (libaom) isn't a good way of thought. I think the actual problem resides in your environment setup. CMake can't identify the compiler (NDK's clang) info for some reason. Even if you managed to skip the CMakeCCompilerId.c compilation, there can (an probably will) be more problems further.

You can try compiling the vanilla ffmpeg-android-maker without any 3rd party libraries and see if it works. Is it a problem with the compiler? Or with how exactly the CMake assesses the compiler? CMake is used only for libaom and mbedtls. Can the latter be compiled?

You can install another Linux image to your Windows machine. Try Ubuntu, for example. It will have a separate environment so you will be able to set it up from scratch. Please follow the Dockerfile mentioned above.

I don't have access to your machine so I can only guess or suggest another way - using the Docker image.

[null4n]

If you want to use fdk-aac, u can try my fork. but I can't help for the libaom issue

[Artim96]

If you want to use fdk-aac, u can try my fork. but I can't help for the libaom issue

Thanks, I already added it as expanded in the wiki myself, even through I haven't tested it yet as libaom is the first thing compiling. As long as the default stuff isn't compiling it doesn't make much sense to care about that.

BTW: anybody can explain, why exactly the cmake version from the Android SDK must be used and not the default one of the distribution? There must be the reason, otherwise trying to figure out what's wrong with the sdk/ndk setup would be a waste of time.

[Javernaut]

why exactly the cmake version from the Android SDK must be used

Not really 'must', but 'preferably'.

I just try to eliminate installing all software the world has on a machine that just wants to compile the FFmpeg. If it is in SDK/NDK already, then why installing it additionally? CMake can be installed via Android SDK, then this is the option I go with. The less dependencies to install (and live with after FFmpeg comilation) - the better.

[Artim96]

why exactly the cmake version from the Android SDK must be used

Not really 'must', but 'preferably'.

I just try to eliminate installing all software the world has on a machine that just wants to compile the FFmpeg. If it is in SDK/NDK already, then why installing it additionally? CMake can be installed via Android SDK, then this is the option I go with. The less dependencies to install (and live with after FFmpeg comilation) - the better.

good to know. So I just replaced CMAKE_EXECUTABLE and MAKE_EXECUTABLE with the paths of the system-wide counterparts, same result. So not a problem with that. I'll try on another system, but it seems strange...

[Artim96]

Compiling in docker worked now. Although strangely building the docker image from scratch didn't work, as a Java Runtime v55 was used, but something else was compiled with v52 and couldn't handle anything above.

@null4n your fork didn't work, not with the prebuilt docker image and building it from source. But also you don't accept issues in your git and I don't see any way to contact you.

@Javernaut I did read that this script does also create a ffmpeg binary that can be executed from the android terminal. What do I have to copy to my device? Just copying build/ffmpeg/arm64-v8a/bin/ffmpeg doesn't do the trick. Is that even the right binary, or is there another static binary?

[null4n]

@Artim96 sorry, I have enabled issue in my fork

[Javernaut]

@Artim96

You can, but you don't need to build the image from scratch. The Docker Hub already has the prebuilt image that you can use. Java v52/v55 thing relates to JDK 8 and 11 issue which I discovered only recently and didn't dive much into it. I presume the sdkmanager doesn't support JDK 8 anymore, so JDK 11 should be used. Again, didn't have time for it yet.

As for the ffmpeg binary, the script just prepares proper parameters for the FFmpeg's build process, that can produce the ffmpeg binary. So technically it is possible to produce that binary, yes. And such a binary does work while being on Android device. Once I made an experiment placing the binary with related shared libraries somewhere in Android device or emulator and could successfully convert a video file to another container and codec. However, this was a pure experiment. So far I have no solid instructions about how to make it conveniently usable via java api for Android app.

I have quite a backlog in jira for this project. Yet I lack time.

[Artim96]

@Javernaut good to know.

[null4n]

to build a static binary, just change scripts/ffmpeg/build.sh. just disable shared and enable static below ./configure \ then you'll get a static ffmpeg binary that can run on any android newer than api21 without any library file

[Artim96]

to build a static binary, just change scripts/ffmpeg/build.sh. just disable shared and enable static below ./configure \ then you'll get a static ffmpeg binary that can run on any android newer than api21 without any library file

Nope, that just leads to the errors your fork is throwing.

[null4n]

to build a static binary, just change scripts/ffmpeg/build.sh. just disable shared and enable static below ./configure \ then you'll get a static ffmpeg binary that can run on any android newer than api21 without any library file

Nope, that just leads to the errors your fork is throwing.

logs? you can create new issue in my fork. I test on my pc and github actions both success