profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/DanAlbert/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Dan Albert DanAlbert Google Mountain View, CA

android/ndk 1158

The Android Native Development Kit

DanAlbert/cryptrd 4

Encrypting RAM disk driver for Linux

DanAlbert/dynamic-cast-repro 3

Repro case for https://github.com/android-ndk/ndk/issues/533

DanAlbert/dcs_liberation 1

DCS World single-player liberation dynamic campaign.

DanAlbert/dnd-tools 1

Tools to track Dungeons and Dragons 3.5 statistics

DanAlbert/dotfiles 1

A template for structuring dotfiles (using Dotbot as an installer)

DanAlbert/.emacs.d 0

My emacs directory

DanAlbert/apollo 0

Apollo 2D Rendering Engine

issue commentandroid/ndk

[FR] unchecked "prebuilt" library type

https://android-review.googlesource.com/c/platform/ndk/+/1833066 does this. I opted for LOCAL_ALLOW_MISSING_PREBUILT rather than a separate module type because it was easier to implement it that way, but it'd be easy to make a new module type that just wraps the old one and sets the property automatically if anyone thinks that's worthwhile.

DanAlbert

comment created time in 20 hours

issue commentandroid/ndk

[BUG] -fsanitize=fuzzer,address fails to link

given that "roughly no-one" uses LTO

Is that true? There's some sampling bias in the bug tracker since it's a more bug-prone part of LLVM, but it seems quite common.

axnsan12

comment created time in a day

issue closedandroid/ndk

[BUG] New cmake toolchain does not correct ANDROID_PLATFORM value

Description

I'm not sure if that is an NDK or Android Gradle plugin bug - probably a bit of both.

WIth legacy toolchain, when android-16 was selected as ANDROID_PLATFORM and arm64-v8a as ANDROID_ABI, the toolchain corrected the ANDROID_PLATFORM value to android-21, as 64-bit platforms are supported only from Android API 21.

This is problematic as Android Gradle Plugin 7.0.2 (bundled with Android Studio Arctic Fox) invokes cmake with ANDROID_ABI equal to minSdkVersion for all ABIs. So, when configuring an app with minSdkVersion set to 16 with no set abiFilters (or having at least one 64-bit ABI), cmake configuration fails with following error:

  -- Check for working C compiler: /Users/dodo/.conan/data/AndroidNdk/r23/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
  -- Check for working C compiler: /Users/dodo/.conan/data/AndroidNdk/r23/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang - broken
  -- Configuring incomplete, errors occurred!
  See also "/Users/dodo/Work/Microblink/Builds/core-utils/clang/dev-release/CoreUtilsTest-android-studio/app/.cxx/Release/c2p1z626/arm64-v8a/CMakeFiles/CMakeOutput.log".
  See also "/Users/dodo/Work/Microblink/Builds/core-utils/clang/dev-release/CoreUtilsTest-android-studio/app/.cxx/Release/c2p1z626/arm64-v8a/CMakeFiles/CMakeError.log".

  CMake Error at /Applications/CMake.app/Contents/share/cmake-3.21/Modules/CMakeTestCCompiler.cmake:69 (message):
    The C compiler

      "/Users/dodo/.conan/data/AndroidNdk/r23/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang"

    is not able to compile a simple test program.

    It fails with the following output:

      Change Dir: /Users/dodo/Work/Microblink/Builds/core-utils/clang/dev-release/CoreUtilsTest-android-studio/app/.cxx/Release/c2p1z626/arm64-v8a/CMakeFiles/CMakeTmp

      Run Build Command(s):/usr/local/bin/ninja cmTC_fa1e9 && [1/2 ?/sec] Building C object CMakeFiles/cmTC_fa1e9.dir/testCCompiler.c.o
      [2/2 91.8/sec] Linking C executable cmTC_fa1e9
      FAILED: cmTC_fa1e9
      : && /Users/dodo/.conan/data/AndroidNdk/r23/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang --target=aarch64-none-linux-android16 --sysroot=/Users/dodo/.conan/data/AndroidNdk/r23/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fexceptions  -O2 -g -DNDEBUG -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--fatal-warnings -Qunused-arguments -Wl,--no-undefined  -Wl,--gc-sections CMakeFiles/cmTC_fa1e9.dir/testCCompiler.c.o -o cmTC_fa1e9  -latomic -lm && :
      ld: error: cannot open crtbegin_dynamic.o: No such file or directory
      ld: error: cannot open crtend_android.o: No such file or directory
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
      ninja: build stopped: subcommand failed.





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

By using legacy toolchain or by setting minSdkVersion to 21 or above, the problem is gone.

Although the AGP clearly invokes CMake in a wrong manner, I think this should also be fixed on the NDK side because it should be possible to use NDK r23 with an older Gradle plugin (Android Studio 4 and earlier) that is not aware of the new cmake toolchain file in NDK r23.

Environment Details

  • NDK Version: r23
  • Build system: CMake
  • Host OS: happens on both MacOS and Linux (haven't tested on Windows, but due to a nature of the issue, it should be reproducible there as well)
  • ABI: arm64-v8a
  • NDK API level: 16

Sample project that demonstrates the issue is attached here: ndkr23bug.zip

closed time in a day

DoDoENT

issue commentandroid/ndk

[BUG] New cmake toolchain does not correct ANDROID_PLATFORM value

Duplicate of #1560

DoDoENT

comment created time in a day

issue commentandroid/ndk

ndk-stack.py fails to symbolise on windows

r23 was released a little while ago, but I don't think ndk-stack has changed since r22. The tools it calls certainly did though, so it's probably worth checking if this is already fixed there.

shrukul

comment created time in a day

MemberEvent

issue commentandroid/ndk

[BUG] -fsanitize=fuzzer,address fails to link

(was talking to @rprichard about this and it sounds like there's some nuance to enabling it, so he'll be along to explain so I don't give you bad info)

axnsan12

comment created time in 2 days

issue commentandroid/ndk

[BUG]show “fcntl(): Bad file descriptor”

First option (dropping -O) is the safest. We should probably start there, especially since it's what we intended to ship. Might end up doing the other in r23c depending on how the M1 work goes?

cyz7758520

comment created time in 2 days

issue commentandroid/ndk

[BUG] -fsanitize=fuzzer,address fails to link

The Clang driver doesn't enable ELF TLS by default for any OS version. Support for that was only added to Android somewhat recently (29?) but we haven't updated the driver to account for it. I think there's an argument you could pass to enable it but I don't know it off the top of my head (on my phone atm but I'll look up both answers in an hour or so).

axnsan12

comment created time in 2 days

issue commentandroid/ndk

[BUG] -fsanitize=fuzzer,address fails to link

Yeah, I figured that was the answer, but it's odd that it doesn't work then. I suspect this might be something that only affects emutls platforms (old versions of Android) and -fsanitize=fuzzer with regular TLS support doesn't need to link the library. I'm not sure what the fix is (probably just teaching the driver to link libfuzzer for libraries too, at least for Android?) but @eugenis should be able to advise.

axnsan12

comment created time in 2 days

issue commentandroid/ndk

[BUG] -fsanitize=fuzzer,address fails to link

@eugenis is -fsanitize=fuzzer valid with libraries? I've only ever seen it with executables, and examining the link command the driver doesn't link libfuzzer at all, even after I replace fuzzer-no-link (which the docs say is for cflags, not ldflags) with fuzzer.

axnsan12

comment created time in 2 days

pull request commentdcs-liberation/dcs_liberation

[WIP] Add possibility to add helipads to FOB control points

Harriers are not expected to work from FARPs yet.

Khopa

comment created time in 3 days

issue commentandroid/ndk

r23~b6 miscompiles some coroutines (fixed upstream, mere days after point of last merge)

@DanAlbert I think you may have to fix the link to the canary build here :)

D'oh! Yeah, my mistake. That build updates the sysroot. https://ci.android.com/builds/branches/aosp-master-ndk/grid?head=7740141&tail=7740141 updates the compiler. Sorry about that.

saurik

comment created time in 6 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Gotcha. That's what I've done, but wasn't sure if that was the intent. Thanks for confirming.

jheydebrand

comment created time in 6 days

issue commentdcs-liberation/dcs_liberation

Carrier-capable aircraft cannot be placed at airfields by campaign designers

it would be preferable to just fix the defaults in /squadrons/operatingbases.py

That's not what this is for. It's just a hint to any AI decisions about what to do with the aircraft. If shore: false and carrier: true, the squadron will prefer a carrier over an airbase when retreating. Before squadrons had assigned bases it was also a hint to the procurement AI about where to buy aircraft.

The bug is that it affects campaign generation.

Starfire13

comment created time in 7 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

For now I've just opted that hook out. We may want to copy/paste that into all the hooks.

jheydebrand

comment created time in 7 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Hmm, although that breaks the legacy toolchain because apparently the hooks are loaded even in that case (where CMAKE_SYSTEM_VERSION is always 1 because that's how we tell CMake to disable all its own behavior). I thought the hooks were only supposed to be used for the non-legacy toolchain? Am I remembering wrong, or is that a bug? If the hooks need to support both workflows that's going to get messy fast.

jheydebrand

comment created time in 7 days

issue commentandroid/ndk

r23~b6 miscompiles some coroutines (fixed upstream, mere days after point of last merge)

https://ci.android.com/builds/branches/aosp-master-ndk/grid?head=7732824&tail=7732824 has the fix. I wasn't able to repro the crash (guessing at build flags didn't get me there) so I can't verify that it fixed the issue.

saurik

comment created time in 7 days

issue commentandroid/ndk

[BUG] Emulated TLS across shared libraries is (more) broken with r23

https://ci.android.com/builds/branches/aosp-master-ndk/grid?head=7732824&tail=7732824 has the fix. I haven't verified the repro case, but it has the cherry-pick that was requested.

smeenai

comment created time in 7 days

issue commentandroid/ndk

Android NDK r22b clang-compiler failed to compile code for AArch32

https://ci.android.com/builds/branches/aosp-master-ndk/grid?head=7732824&tail=7732824 has the fix for this. I was able to verify that locally.

pavel-zhigulin

comment created time in 7 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Uploaded https://android-review.googlesource.com/c/platform/ndk/+/1829052 to apply the workaround better and https://android-review.googlesource.com/c/platform/ndk/+/1829092 to make it non-permanent, since Brad already has a fix up targeted at 3.22. We shouldn't submit the latter until the CMake fix actually lands so not on autosubmit.

jheydebrand

comment created time in 7 days

PullRequestReviewEvent

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Not so much a mess as just I haven't taken the time to learn it yet :)

jheydebrand

comment created time in 7 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Aha, thanks! I'll try that change tomorrow. I'd poked around in a few of the hooks but whatever I'd tried didn't work. Haven't really gotten familiar with the new system yet.

jheydebrand

comment created time in 8 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

https://android-review.googlesource.com/c/platform/ndk/+/1827522 adds a workaround.

jheydebrand

comment created time in 8 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Okay, looks like I can add this to the (new) toolchain file as a workaround:

if(CMAKE_ANDROID_ARCH_ABI STREQUAL armeabi-v7a)
  set(ANDROID_LLVM_TRIPLE armv7-none-linux-androideabi)
elseif(CMAKE_ANDROID_ARCH_ABI STREQUAL arm64-v8a)
  set(ANDROID_LLVM_TRIPLE aarch64-none-linux-android)
elseif(CMAKE_ANDROID_ARCH_ABI STREQUAL x86)
  set(ANDROID_LLVM_TRIPLE i686-none-linux-android)
elseif(CMAKE_ANDROID_ARCH_ABI STREQUAL x86_64)
  set(ANDROID_LLVM_TRIPLE x86_64-none-linux-android)
else()
  message(FATAL_ERROR "Invalid Android ABI: ${ANDROID_ABI}.")
endif()
set(CMAKE_C_COMPILER_TARGET "${ANDROID_LLVM_TRIPLE}${CMAKE_SYSTEM_VERSION}")
set(CMAKE_CXX_COMPILER_TARGET "${ANDROID_LLVM_TRIPLE}${CMAKE_SYSTEM_VERSION}")

(thanks Brad for the hint on the other bug)

It won't help anyone not using our toolchain file, but I wasn't having any luck finding another way to do it, and our toolchain file is the workflow with the regression, so I think that's probably fine?

jheydebrand

comment created time in 8 days

issue commentandroid/ndk

[BUG] CMake 3.21 + NDK r23 sets MINGW=1 in CMake

Thanks for confirming. Filed https://gitlab.kitware.com/cmake/cmake/-/issues/22647

We might be able to forcibly add the target argument to the compiler name so that CMake can't avoid it in compiler ID, but idk if that'll cause other problems.

If that doesn't work we probably need to bump the CMake version that's required for using the non-legacy toolchain since this does render this path quite unusable on windows (and probably has subtle bugs elsewhere). Unfortunately that would mean effectively unshipping this feature for now since there obviously is no CMake version with the fix yet.

jheydebrand

comment created time in 8 days

issue commentandroid/ndk

[BUG] Default release flags changed to O3 with unified cmake toolchain in r23-beta5

Just set your flags the way you want them.

Sfairat

comment created time in 8 days

issue commentandroid/ndk

[BUG] NDK 23.0 with CMake 3.21: "clang++ is not able to compile a simple test program"

The fix needed a fix: https://android-review.googlesource.com/c/platform/ndk/+/1826816/. Whoever does the cherry-picks make sure you get both :)

Boris-Rasin

comment created time in 9 days

issue commentandroid/ndk

[BUG] Default release flags changed to O3 with unified cmake toolchain in r23-beta5

Decided to go that route. It's submitted and will be in r23b.

Sfairat

comment created time in 9 days