Attempting to compile an error for arm64 Linux

[kero990]

I tried to compile this project for an arm64 Linux, but frequently encountered the following errors

cc1plus: error: unknown value ‘armv8’ for -march
cc1plus: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a native; did you mean ‘armv8-a’?

This should just be a simple parameter issue, but unfortunately I don't know where to modify it.

[WyvernZhao]

These architecture related parameters are located in CMakeLists.txt files. Unfortunately I don't have a 'arm64 linux' environment, so you have to test it by yourself. Search all the project, you should find the following CMakeLists.txt files that have this arch parameter in it:

1. ./CMakeLists.txt, at line 22,23
2. ./blueprintsdk/CMakeLists.txt, at line 21,22
3. ./imgui/CMakeLists.txt, at line 111,112
4. ./imgui/addon/ImVulkanShader/CMakeLists.txt, at line 48,49

Try to change the parameter from 'armv8' to a valid value for your compiler (maybe 'armv8-a'), and see if it can solve your problem.

[kero990]

Thank you for your reply. I have modified CMakeLists.txt according to the above instructions, but currently I have received the following error message

/root/MediaEditor/imgui/immat.h:2634:23: error: cannot convert ‘int8x16_t’ {aka ‘__vector(16) signed char’} to ‘uint8x16_t’ {aka ‘__vector(16) unsigned char’}
         X = vqsubq_u8(X, V);
                                  ^

There are many, but they all seem to be one type of error It seems that the code needs to be adapted to arm64 before it can be used. Or is choosing armv8-a incorrect for my device?

[WyvernZhao]

The error looks like just a type mismatch error. You could try to add an explicit type conversion indicator as: X = vqsubq_u8(X, V); -------------> X = vqsubq_u8((uint8x16_t)X, (uint8x16_t)V); and check if the error can be resolved. Can you share your system information (CPU, OS info) and the name and version of your compiler? We can try to setup a similar environment to check the compilation issues and verify the MEC app on it.

[kero990]

After modification, this will result in a similar but opposite type warning

/root/MediaEditor/imgui/immat.h:2634:52: error: cannot convert ‘uint8x16_t’ {aka ‘__vector(16) unsigned char’} to ‘int8x16_t’ {aka ‘__vector(16) signed char’} in assignment
/root/MediaEditor/imgui/immat.h: In function ‘void ImGui::sub_int16_neon(int16_t*, const int16_t*, size_t, int16_t)’:

My device is a standard arm64v8 device, but due to driver limitations, it is only available in the debian10 environment and cannot be upgraded to higher system versions. All compilers and libraries are native to debian10.

I am accustomed to compiling the source code myself, because even if an open-source project has an arm64 release, it is likely to report that the glibc version is too low (<=2.28) and cannot run

[WyvernZhao]

You could try to change the line into: X = vqsubq_u8(X, V); -------------> X = (int8x16_t)vqsubq_u8((uint8x16_t)X, (uint8x16_t)V); Since variable X, V is declared as singed int8 vector type 'int8x16_t', and intrinsic 'vqsubq_u8' works on unsinged vector type 'uint8x16_t', and your compiler doesn't support implicit type conversion between these types, you have to use explicit type conversion indicator.

BTW, could you share your compiler information? Use 'gcc -v' (or similar command if you're not using gcc) to show the version info.

[kero990]

X = (int8x16_t)vqsubq_u8((uint8x16_t)X, (uint8x16_t)V);

After solving the above problem, the current error is

MediaEditor/MediaCore/src/FFUtils.cpp:80:15: error: ‘AV_PIX_FMT_NV24’ was not declared in this scope
     format == AV_PIX_FMT_NV24 || \
                       ^~~~~~~~~~~~~~~

MediaEditor/MediaCore/src/FFUtils.cpp:2402:37: error: ‘using element_type = struct AVFrame’ {aka ‘struct AVFrame’} has no member named ‘duration’; did you mean ‘pkt_duration’?
         return m_hAvfrm ? m_hAvfrm->duration : 0;
                                                            ^~~~~~~~
                                                            pkt_duration

My GCC version is 8.3, I'm not sure if it can be implemented in the end.

$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/8/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

[WyvernZhao]

:sweat_smile: I knew this would happen. This is due to the version of your ffmpeg-library is too low. Our releases are packaged with the ffmpeg libraries built by ourselves to avoid this ffmpeg-version-mismatch situation. You can check the version of your ffmpeg & libav*.so libraries by ffmpeg -version. Mine is like:

ffmpeg version n6.0-17-g8f61cbf1b9 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04)
configuration: --enable-shared --disable-static --enable-gpl --enable-nonfree --enable-gnutls --enable-libass --enable-libfdk-aac 
--enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libaom --enable-libsvtav1 --enable-libdav1d --enable-libvorbis 
--enable-libvpx --enable-libx264 --enable-libx265 --enable-libvidstab --enable-cuvid --enable-nvenc --enable-libmfx --enable-libglslang
libavutil      58.  2.100 / 58.  2.100
libavcodec     60.  3.100 / 60.  3.100
libavformat    60.  3.100 / 60.  3.100
libavdevice    60.  1.100 / 60.  1.100
libavfilter     9.  3.100 /  9.  3.100
libswscale      7.  1.100 /  7.  1.100
libswresample   4. 10.100 /  4. 10.100
libpostproc    57.  1.100 / 57.  1.100

My suggestion is to use a later version of ffmpeg than 'n5.0'. If you can not get it from your apt repository, you can build it from code on FFmpeg github repo, and check out a release tag. To build an adequate version of ffmpeg, consider using the following configuraton:

configure --enable-shared --disable-static --enable-gpl --enable-nonfree --enable-gnutls --enable-libass
--enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx 
--enable-libx264 --enable-libx265 --enable-libvidstab

If you have Nvidia graphics card, you could add --enable-cuvid --enable-nvenc to enable hardware acceleration codec for it. After the ffmpeg is built, don't forget to install it by sudo make install. The built version of ffmpeg CLI should be installed to /usr/local/bin/, the libav*.so libraries should be installed to /usr/local/lib/, and header files to /usr/local/include/.

[kero990]

After compiling and installing ffmpeg, the compilation progress can now reach 100%, but errors are reported again during the linking phase

[100%] Linking CXX executable mec
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::path::has_root_directory() const'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::path::has_filename() const'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::status(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::create_directory(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::remove_all(std::filesystem::__cxx11::path const&, std::error_code&)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::symlink_status(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::remove(std::filesystem::__cxx11::path const&, std::error_code&)'
/usr/bin/ld: libBaseUtils.so.0.1.0: undefined reference to `std::filesystem::create_directories(std::filesystem::__cxx11::path const&)'
collect2: error: ld returned 1 exit status

My attempts to add (CMAKE-CXX_STANDARD 17, CMAKE-CXX-FLAGS "- lstdc++fs") to the CMakeLists.txt of the project and BaseUtils were unsuccessful. Can you please advise on how to resolve this final issue

Also, I would like to ask, for ARM devices, they are generally not independent graphics cards like NV, but ARM's built-in core display, and the CPU computing power of ARM chips is relatively weak. How can ARM also support hardware decoding? I am worried that even if the program can be compiled and run, it will still be in an unusable state for pure CPU computing.

[kero990]

@WyvernZhao Hi, after continuous Google, I have resolved the above issues and successfully compiled the project. I modified the cmake file of appimage to generate the correct package, but unfortunately, it was not possible to run the /mec directly, or the . appimage. All prompt segment errors. vkCreateInstance failed -9 segment errors This is probably not something that compilation can solve. More investigation is needed.

Thank you for your continuous response. Looking forward to the day when it can run across architectures. Thank you

[WyvernZhao]

Sorry, I missed your previous reply, didn't see the notification. Anyway, I'm happy for you that you've finally resolved the compilation issues :clap:. For the vkCreateInstance-fail issue, it's probably related to the vunlkan library on your platform. Although the UI framework 'imgui' supports multiple render backends other than Vulkan, such as OpenGL, our MEC has many internal graphic-related algorithms relied on Vulkan. I think there are two ways you could try to solve your problem:

1. Install a later version of vulkan sdk from here.
2. Use OpenGL as render backend and disable vulkan shader code. To do this, open your CMake virables editor (if you're using vscode, press Ctl+Shift+P and search for CMake: Edit CMake Cache (UI)), search the virables with keyword 'VULKAN', then uncheck the options IMGUI_VULKAN and IMGUI_VULKAN_SHADER. You could try to uncheck IMGUI_VULKAN first and test if the compiled mec could work. If it still fails, then uncheck IMGUI_VULKAN_SHADER, this will disable many features in MEC which those features are only implemented by vulkan shader.