8.4.0 fails to build on cross-compiled android ARM #12086
Comments
|
Does Android/bionic actually have fseeko? If so, where is it defined?
|
|
ubuntu@7a4b33d7e1d4:/$ nm -D /android-ndk-arm/sysroot/usr/lib/libc.so | grep fseeko |
|
Nearly the same output in the CI here: Seems to depend on the target min SDK version: https://stackoverflow.com/questions/55571842/android-error-use-of-undeclared-identifier-fseeko Snippet from stdio.h: |
|
As a quick and dirty workaround, I skipped the fseeko check for android. diff -Naur a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt 2023-10-09 08:21:51.000000000 +0200
+++ b/CMakeLists.txt 2023-10-11 12:53:58.055399342 +0200
@@ -1180,7 +1180,9 @@
check_symbol_exists(freeaddrinfo "${CURL_INCLUDES}" HAVE_FREEADDRINFO)
check_symbol_exists(pipe "${CURL_INCLUDES}" HAVE_PIPE)
check_symbol_exists(ftruncate "${CURL_INCLUDES}" HAVE_FTRUNCATE)
-check_symbol_exists(fseeko "${CURL_INCLUDES};stdio.h" HAVE_FSEEKO)
+if(CMAKE_SYSTEM_NAME NOT STREQUAL Android)
+ check_symbol_exists(fseeko "${CURL_INCLUDES};stdio.h" HAVE_FSEEKO)
+endif()
check_symbol_exists(_fseeki64 "${CURL_INCLUDES};stdio.h" HAVE__FSEEKI64)
check_symbol_exists(getpeername "${CURL_INCLUDES}" HAVE_GETPEERNAME)
check_symbol_exists(getsockname "${CURL_INCLUDES}" HAVE_GETSOCKNAME)
diff -Naur a/configure.ac b/configure.ac
--- a/configure.ac 2023-10-05 09:58:50.000000000 +0200
+++ b/configure.ac 2023-10-11 13:13:07.486490432 +0200
@@ -3577,6 +3577,14 @@
;;
esac
+case $host in
+ *android*)
+ ac_cv_func_fseeko=no
+ skipcheck_fseeko=yes
+ AC_MSG_NOTICE([skip check for fseeko on android])
+ ;;
+esac
+
AC_CHECK_DECLS([getpwuid_r], [], [AC_DEFINE(HAVE_DECL_GETPWUID_R_MISSING, 1, "Set if getpwuid_r() declaration is missing")],
[[#include <pwd.h>
#include <sys/types.h>]]) |
|
Another workaround is configuring with: I wonder why the detection and use turn out differently. Does this help perventing false-detection with CMake?: diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1b19c681d..23cd906dc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1180,7 +1180,7 @@ check_symbol_exists(getifaddrs "${CURL_INCLUDES};stdlib.h" HAVE_GETIFADDRS)
check_symbol_exists(freeaddrinfo "${CURL_INCLUDES}" HAVE_FREEADDRINFO)
check_symbol_exists(pipe "${CURL_INCLUDES}" HAVE_PIPE)
check_symbol_exists(ftruncate "${CURL_INCLUDES}" HAVE_FTRUNCATE)
-check_symbol_exists(fseeko "${CURL_INCLUDES};stdio.h" HAVE_FSEEKO)
+check_symbol_exists(fseeko "stdio.h" HAVE_FSEEKO)
check_symbol_exists(_fseeki64 "${CURL_INCLUDES};stdio.h" HAVE__FSEEKI64)
check_symbol_exists(getpeername "${CURL_INCLUDES}" HAVE_GETPEERNAME)
check_symbol_exists(getsockname "${CURL_INCLUDES}" HAVE_GETSOCKNAME) |
|
https://android.googlesource.com/platform/bionic/+/refs/heads/main/docs/32-bit-abi.md |
|
Please try #12086 (comment) and report if it changes detection results. It could clear the question if anything in |
|
@12932 this still seems to imply that configure found the |
Maybe the required defines for the minimum targed sdk are missing there, so that it finds it? |
The check links a test program that uses the symbol, and the linking works. So the function is definitely present there. So yes it could be a problem with the define, if the define causes the symbol to somehow get redefined and make it not found by the linker. |
|
But: and the check in stdio.h is based on But seems to trigger. It also triggers if I write |
|
Those are just defines that don't change the fseeko name though. So they will not prevent the linker from finding the fseeko function that you evidently have. |
|
Doesn't it? |
The prototype being provided in that header only changes if you get a compiler warning or not, it does not prevent the function from being able to link. |
|
Oups - too many terminals open error. You're right, I just tricked myself. Sorry. |
|
Does |
So yes, this is a compiler warning you turn into an error with The function is however present in libc, so chances are it would work if you removed that compiler option? |
We actually set Line 529 in 81c9c8c It was actually me who did that in 9168e24. That's because it's required for C99 and later anyway. (Edit: ah no, that's for GCC, and the Android toolchain uses clang.) |
ndk uses the same libc.so for all API levels |
Sure, because it makes sense. But this Android setup does not make sense... |
|
And the method is available for 32bit abi >= 24 only. I need to build for >= 23. If I do it compiles and links. Can't say if it works. |
|
Crash at runtime unless static build. |
... and make the code require both symbol and declaration. This is because for Android, the symbol is always present in the lib at build-time even when not actually available in run-time. Reported-by: 12932 on github Fixes #12086
|
Please try if #12158 works for Android builds. It now requires that the declaration is also present before using fseeko function. If this works, we also need to add a similar check in cmake. |
|
Sorry i've been quiet, I have been busy with other things
I'm not a fan of it either 😭 I'll try out #12158 tomorrow |
|
Just placed the patch in the CI. Using autotools: armv7: armv8: Both targets build. No runtime test yet. |
|
I think this is good enough and I am going to proceed and merge the current fix, as it at least is a step forward. |
... and make the code require both symbol and declaration. This is because for Android, the symbol is always present in the lib at build-time even when not actually available in run-time. Assisted-by: Viktor Szakats Reported-by: 12932 on github Fixes curl#12086 Closes curl#12158
I did this
Build curl:
I expected the following
Curl to build successfully
curl/libcurl version
NA
operating system
Linux 7a4b33d7e1d4 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: