_fseeki64 incorrectly detected as found when cross-compiling for iOS. #15525

lhunath · 2024-11-08T16:44:04Z

I did this

It appears the change introduced by #15164 caused an issue cross-compiling curl for iOS/aarch64.

With the following in CMakeLists.txt:

check_function_exists("_fseeki64"     HAVE__FSEEKI64)

Running the following:

cmake -B libcurl-iphoneos -S libcurl -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_OSX_DEPLOYMENT_TARGET=12.0 -DCMAKE_TOOLCHAIN_FILE=/Users/hubstaff/Developer/hubstaff/ios/hubstaff-core/toolchains/ios.toolchain.cmake -DCMAKE_INSTALL_PREFIX=/Users/hubstaff/Developer/hubstaff/ios/hubstaff-core/build/__third_party__/curl/distro/ios/ -DBUILD_CURL_EXE=OFF -DBUILD_SHARED_LIBS=OFF -GXcode -DBUILD_EXAMPLES=OFF -DBUILD_LIBCURL_DOCS=OFF -DBUILD_MISC_DOCS=OFF -DENABLE_CURL_MANUAL=OFF -DCURL_USE_SECTRANSP=ON -DUSE_APPLE_IDN=ON -DUSE_NGHTTP2=OFF -DCURL_USE_LIBPSL=OFF

Results in:

-- Looking for _fseeki64
-- Looking for _fseeki64 - found

And a failed build:

/Users/hubstaff/Developer/hubstaff/ios/hubstaff-core/build/__third_party__/curl/libcurl/lib/formdata.c:797:10: error: call to undeclared function '_fseeki64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  797 |   return _fseeki64(stream, (__int64)offset, whence);
      |          ^
/Users/hubstaff/Developer/hubstaff/ios/hubstaff-core/build/__third_party__/curl/libcurl/lib/formdata.c:797:29: error: use of undeclared identifier '__int64'
  797 |   return _fseeki64(stream, (__int64)offset, whence);
      |                             ^
/Users/hubstaff/Developer/hubstaff/ios/hubstaff-core/build/__third_party__/curl/libcurl/lib/formdata.c:794:52: warning: unused parameter 'offset' [-Wunused-parameter]
  794 | static int fseeko_wrapper(void *stream, curl_off_t offset, int whence)
      |                                                    ^
1 warning and 2 errors generated.

While reverting the CMakeLists.txt back to using:

check_symbol_exists("_fseeki64"       "${CURL_INCLUDES};stdio.h" HAVE__FSEEKI64)

Yields:

-- Looking for _fseeki64
-- Looking for _fseeki64 - not found

And a successful build.

I expected the following

For HAVE__FSEEKI64 to be correctly detected as 0 rather than 1 when the symbol is unavailable during build time.

curl/libcurl version

curl-8_11_0

operating system

Cross-compiling for iPhoneOS18.1.sdk from macOS 15.0.1 (24A348).

The text was updated successfully, but these errors were encountered:

vszakats · 2024-11-08T17:43:13Z

Thanks for your report.

Would you mind posting the lines from CMakeFiles/CMakeConfigureLog.yaml where this detection is made?

Also if you could make a ./configure build for iOS, it would be helpful to see if it's (mis)detected there.

Detecting `_fseeki64` can be tricky, but also seems redundant given that it's Windows-only and we already opt-in all Windows builds to use it (in CMake). Drop detections and use it in all Windows builds with large file support enabled. Regression-from: 8e34505 curl#15164 Reported-by: Maarten Billemont Fixes curl#15525

vszakats · 2024-11-08T18:12:28Z

I figure it may be a more effective approach to just skip the detection
altogether. Patch proposal: #15526.

Unless someone is aware that _fseeki64() is offered anywhere else
than Windows.

Also related:

pririotizing it for Windows: aaacd02 GHA/configure-vs-cmake: add Windows build, fix issues #14678 f365d50
cmake opt-in for Windows: 8e74c07 cmake: assume _fseeki64 and no fseeko on Windows #11950
opt-in Windows: aa6c94c config-win32: define HAVE__FSEEKI64 #11944
initial support: 9c7165e lib: use wrapper for curl_mime_data fseek callback #11918

vszakats · 2024-11-08T18:24:33Z

In the meantime for anyone bumping into this issue, the workaround is passing -DHAVE__FSEEKI64=OFF to the cmake command-line.

It's not offered by Apple operating system, but in some cases it may get mis-detected when using `check_function_exists()`, then making the build fail later. A better fix would be to figure out why are these mis-detections. One common pattern seen is this option, but it may or not be the cause: ``` -DCMAKE_TOOLCHAIN_FILE=[...]/toolchains/ios.toolchain.cmake ``` Ref: curl#15525 Regression from 8e34505 curl#15164 Reported-by: Dan Rosser Fixes curl#15557 Closes curl#15558

It's not offered by Apple operating systems, but in some cases it gets mis-detected when using `check_function_exists()`. Then making the build fail later. A better fix would be to figure out why are these mis-detections. One common pattern seen is this option, but it may or not be the cause: ``` -DCMAKE_TOOLCHAIN_FILE=[...]/toolchains/ios.toolchain.cmake ``` Ref: curl#15525 Regression from 8e34505 curl#15164 Reported-by: Dan Rosser Fixes curl#15557 Closes curl#15558

vszakats · 2024-11-12T14:36:06Z

@lhunath Can you give a pointer where to find the referencedtoolchains/ios.toolchain.cmake file?

vszakats · 2024-11-12T15:32:42Z

I could trace this back to an issue in ios.toolchain.cmake.
Details and possible upstream workaround:
#15559 (comment)

It's not offered by Apple operating systems, but in some cases it gets mis-detected when using `check_function_exists()`. Then making the build fail later. A better fix would be to figure out why are these mis-detections. One common pattern seen is this option, but it may or not be the cause: ``` -DCMAKE_TOOLCHAIN_FILE=[...]/toolchains/ios.toolchain.cmake ``` Ref: curl#15525 Regression from 8e34505 curl#15164 Reported-by: Dan Rosser Fixes curl#15557 Closes curl#15558

* OpenSSL [3.3.1~3.4.0] - https://github.com/openssl/openssl/blob/master/CHANGES.md - Formulae: Fix for tag on cmake script / SHA * cURL [8.9.1 ~ 8.11.0] - Changelog https://curl.se/ch/8.11.0.html - Formulae - updated SHA / tag * cURL - Cmakelist : FSEEK disabled till next version curl/curl#15525 * cURL macOS Getpass fix * cURL macOS patch 8.11.0 * cURL Disable LibPSL / LibSSH sub (cherry picked from commit 7bd3c0f) * cURL HAVE_GETPASS_R=0 * cURL CMake macOS ignore homebrew subs (cherry picked from commit b89902a) * cURL enable -DENABLE_STRICT_TRY_COMPILE=ON * cURL / OpenSSL no package registry * cURL disable PSL/SSH

Fix builds with CMake configured to falsely return successful detection when using `check_function_exists()` (and `check_library_exists()`, and anything based on `try_compile()` that's relying on the linker). After such mis-detection the build fails when trying to use the feature that doesn't in fact exist. The mis-detection is caused by this CMake setting: ``` set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) ``` It is set by default (or on conditions) when using 3rd-party toolchain: https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake After this patch the curl build overrides this setting for the duration of feature tests, and logs a message about it. Also preset and skip feature tests for known mis-detections: - `connect()` in `libsocket` - `getpass_r()` - `eventfd()` (did not cause an issue due to a separate bug) - `sendmmsg()` (did not cause an issue because it's Linux-only) If mis-detections are still seen, the workaround is to force-set the specific feature by passing `-DHAVE_*=OFF` to cmake. Also consider passing `-DENABLE_STRICT_TRY_COMPILE=ON` for `ios.toolchain.cmake` to fix the root cause. Interestingly curl itself uses this setting to speed up compile-only detections: be17f29 #3744 Also: - OtherTests.cmake: restore original value of `CMAKE_TRY_COMPILE_TARGET_TYPE`. Before this patch it reset it to empty. - OtherTests.cmake: unset a local variable after use, quote a string. Follow-up to 8e34505 #15164 Follow-up to 8b76a8a #15525 Ref: leetal/ios-cmake#47 Ref: https://gitlab.kitware.com/cmake/cmake/-/issues/18121 Ref: https://cmake.org/cmake/help/latest/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html Reported-by: Dan Rosser Fixes #15557 Closes #15559

A recent update caused CMake builds to mis-detect this symbol on iOS. Auto-detection also seems redundant given that it's a Windows-only function and most Windows builds were already opted-in. Drop detections and use it in all Windows builds with large file support enabled. Feature history: - pririotizing for Windows: aaacd02 curl#14678 - Windows opt-in cmake: 8e74c07 curl#11950 - Windows opt-in: aa6c94c curl#11944 - use in libcurl: 9c7165e curl#11918 - use in example: 817d1c0 Regression from 8e34505 curl#15164 Reported-by: Maarten Billemont Fixes curl#15525 Closes curl#15526

bagder added cmake appleOS specific to an Apple operating system labels Nov 8, 2024

vszakats mentioned this issue Nov 8, 2024

build: use _fseeki64() on Windows, drop detections #15526

Closed

vszakats added the regression label Nov 8, 2024

vszakats closed this as completed in 8b76a8a Nov 11, 2024

danoli3 added a commit to danoli3/apothecary that referenced this issue Nov 12, 2024

cURL - Cmakelist : FSEEK disabled till next version curl/curl#15525

52f216b

vszakats mentioned this issue Nov 12, 2024

8.11.0 - macOS getpass_r error building CMake #15557

Closed

vszakats mentioned this issue Nov 12, 2024

cmake: work around ios.toolchain.cmake breaking feature-detections #15559

Closed

vszakats removed the regression label Nov 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

_fseeki64 incorrectly detected as found when cross-compiling for iOS. #15525

_fseeki64 incorrectly detected as found when cross-compiling for iOS. #15525

lhunath commented Nov 8, 2024

vszakats commented Nov 8, 2024

vszakats commented Nov 8, 2024 •

edited

Loading

vszakats commented Nov 8, 2024

vszakats commented Nov 12, 2024 •

edited

Loading

vszakats commented Nov 12, 2024

_fseeki64 incorrectly detected as found when cross-compiling for iOS. #15525

_fseeki64 incorrectly detected as found when cross-compiling for iOS. #15525

Comments

lhunath commented Nov 8, 2024

I did this

I expected the following

curl/libcurl version

operating system

vszakats commented Nov 8, 2024

vszakats commented Nov 8, 2024 • edited Loading

vszakats commented Nov 8, 2024

vszakats commented Nov 12, 2024 • edited Loading

vszakats commented Nov 12, 2024

vszakats commented Nov 8, 2024 •

edited

Loading

vszakats commented Nov 12, 2024 •

edited

Loading