Skip to content
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

3.0.1 doesn't build on armeabi-v7a #393

Open
cmannett85-arm opened this issue Jan 3, 2024 · 1 comment
Open

3.0.1 doesn't build on armeabi-v7a #393

cmannett85-arm opened this issue Jan 3, 2024 · 1 comment
Labels
compatibility Compatibility with some platforms input needed Waiting for more information

Comments

@cmannett85-arm
Copy link

3.0.1 doesn't build on armeabi-v7a, although judging by the error output I can't see how would build on any 32bit system:

FAILED: CMakeFiles/demos.dir/vk/vk_test.cpp.o 
/tools/android-sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=armv7-none-linux-androideabi23 --sysroot=/tools/android-sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/linux-x86_64/sysroot  -DHAVE_SHADERC=1 -DVK_USE_PLATFORM_ANDROID_KHR=1 -Ddemos_EXPORTS -I/tools/android-sdk/ndk/26.1.10909125/sources/android/native_app_glue -I/tools/android-sdk/ndk/26.1.10909125/sources/third_party/shaderc/include -I/home/xxxx/workspace/arm/renderdoc/development/util/test/demos/vk/official -I/home/xxxx/workspace/arm/renderdoc/development/util/test/demos -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security   -std=c++11 -Werror -Wno-unused-result -Wno-nullability-completeness -O3 -DNDEBUG  -fPIC   -Wno-deprecated-declarations -MD -MT CMakeFiles/demos.dir/vk/vk_test.cpp.o -MF CMakeFiles/demos.dir/vk/vk_test.cpp.o.d -o CMakeFiles/demos.dir/vk/vk_test.cpp.o -c /home/xxxx/workspace/arm/renderdoc/development/util/test/demos/vk/vk_test.cpp
In file included from /home/xxxx/workspace/arm/renderdoc/development/util/test/demos/vk/vk_test.cpp:97:
In file included from /home/xxxx/workspace/arm/renderdoc/development/util/test/demos/vk/vk_headers.h:89:
/home/xxxx/workspace/arm/renderdoc/development/util/test/demos/3rdparty/VulkanMemoryAllocator/vk_mem_alloc.h:9938:91: error: cannot cast from type 'VmaAllocHandle' to pointer type 'Block *'
    VkDeviceSize GetAllocationOffset(VmaAllocHandle allocHandle) const override { return ((Block*)allocHandle)->offset; };
                                                                                          ^~~~~~~~~~~~~~~~~~~

For context I was running a development RenderDoc demos 32bit APK build. The issue here is that on 32bit systems VmaAllocHandle is defined as a uint64_t (vulkan_core.h:60), which won't cast to a 32bit pointer type.

@adam-sawicki-a adam-sawicki-a added compatibility Compatibility with some platforms investigating Still to be determined whether we work on this labels Jan 4, 2024
@medranSolus
Copy link

Hello! This seems like issue with how integers can be casted to pointer types on this specific system. VmaAllocHandle is used as an opaque 64 bit handle for different algorithms and that's why it needs to be defined as uint64_t. But in TLSF algorithm it's used as pointer to allocated blocks so on 32 bit system we wouldn't need upper 32 bits. Could you try replacing all usages that are causing problems here with additional cast to uintptr_t? This should firstly cast 64 bit value to per system pointer width so compiler shouldn't complain here, ex. ((Block*)((uintptr_t)allocHandle))? Please tell us if it'll fix this issue.

@adam-sawicki-a adam-sawicki-a added input needed Waiting for more information and removed investigating Still to be determined whether we work on this labels Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with some platforms input needed Waiting for more information
Projects
None yet
Development

No branches or pull requests

3 participants