Arch Linux User Repository

Changes added, thanks!

I understand if you want to keep the environment/wrapper packages on the AUR more streamlined. (Especially also because Google does not say much about -fno-plt. At least I couldn't find a notice that the usage is discouraged; but also not a notice that it is recommended.)

One further remark on that: I suppose keeping -fno-plt where possible is actually the most streamlined option, though. The targets that don't support that flag seem to simply always don't use PLT. So using -fno-plt where possible keeps it disabled everywhere consistently.

By the way, this is my change to remove -fno-plt where PLT isn't supported anyway: https://github.com/Martchus/PKGBUILDs/commit/075aaa4742a3827bf684d21d5f950304ac46c68f

If I invoke this command I can indeed reproduce the warning:

/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang++ -O2 -pipe -fno-plt -fexceptions  -rdynamic -shared -o main.so main.cpp
clang++: warning: argument unused during compilation: '-fno-plt' [-Wunused-command-line-argument]

However, I cannot reproduce it when targeting aarch64:

/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang++ -O2 -pipe -fno-plt -fexceptions -isystem/opt/android-libs/aarch64/include -rdynamic -shared -o main.so main.cpp

This is also consistent with the package build errors where only armv7a-eabi is affected.

For the sake of completeness I've just tested all archs. It doesn't seem to be a 32-bit vs. 64-bit problem because i686 works also with -fno-plt and on the other hand riscv64 is failing, too.

So -fno-plt only needs to be omitted when targeting armv7a-eabi and riscv64. So I would also only omit it then because this flag is probably still a good idea in general. At least that's what I'm now going for with the packages in my repo. I understand if you want to keep the environment/wrapper packages on the AUR more streamlined. (Especially also because Google does not say much about -fno-plt. At least I couldn't find a notice that the usage is discouraged; but also not a notice that it is recommended.)

I found it, this was the warning I said, and happened with 64 bits architectures:

clang: warning: argument unused during compilation: '-fno-plt' [-Wunused-command-line-argument]

There are a few packages that still has this flag defined manually.

Ok - I'm not aware of any warnings on 64-bit archs, though. I guess I'll have a closer look my self out of curiosity. I'm also interested in what errors/warnings one gets exactly as most build errors I've seen so far where just from the config system and the actual compiler/linker output wasn't shown. It just bugs me as using -fno-plt should be possible on Android - at least I couldn't find anything that speaks against it somewhere in the documentation from Google.

-fno-plt was already throwing warnings in the past in 64 bits architectures, but since it was harmless I let it there, now it's throwing errors, that's why I have removed it. I just added those flags because I wanted to mimic the original makepkg flags.

I'm also still wondering why this flag causes these build errors and how updating the NDK from r28.b to r29 is still related.

I don't remember having this errors before, and I keep the binaries in a local repository, and only update then when a new version is released in the arch repository, so these errors were not present on previous NDK versions for sure.

Thanks - although I'm not sure whether that's the best idea as -fno-plt is usually a good idea as it helps reducing call overhead - also see my comment on https://aur.archlinux.org/packages/android-environment#comment-1057329. So maybe remove the flag only on archs where it causes problems.

I'm also still wondering why this flag causes these build errors and how updating the NDK from r28.b to r29 is still related.

Fixed! it was the -fno-plt option that was causing the build failures. Update android-environment and android-meson.

Ok wait, I was checking, and I was building with an old version of the NDK (r28.b) when the current one is r29, that could be the difference. Will check further.

Thanks for your answer. Then it makes sense to investigate this further. I suppose I should start with debug-printing the exact CFLAGS/CXXFLAGS/... that end up in the environment in my build setup. I build the packages in a clean chroot so there shouldn't be much special about my build setup, though.