This is the iOS toolchain file btw: https://github.com/jhasse/jngl/blob/8245a923f2878e9ced930da0183d90e54d8cbeb2/cmake/iOS.toolchain.cmake
--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/e1c3e923-75bb-4ab2-b736-a3827166ff92n%40webmproject.org.
Hi,I invoke CMake like this to generate an Xcode project:cmake -Bbuild-ios -GXcode -DCMAKE_TOOLCHAIN_FILE=cmake/iOS.toolchain.cmake -DIOS_PLATFORM=SIMULATOR
Could you provide the contents of the toolchain file?
On a x86-64 Mac using:cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_ARCHITECTURES=arm64 \-DWEBP_BUILD_DWEBP=0 -DWEBP_BUILD_CWEBP=0 \-DWEBP_BUILD_IMG2WEBP=0 -DWEBP_BUILD_WEBPINFO=0 \-DWEBP_BUILD_WEBPMUX=0 -DWEBP_BUILD_EXTRAS=0will generate a libwebpdecoder.a with the correct symbols, even if I force the -simulator flag (-DIOS_PLATFORM=SIMULATOR wasn't recognized for me using cmake 3.20.5).
On Sunday, 11 July 2021 at 02:03:53 UTC+2 James Zern wrote:Could you provide the contents of the toolchain file?This is the toolchain file: https://github.com/jhasse/jngl/blob/8245a923f2878e9ced930da0183d90e54d8cbeb2/cmake/iOS.toolchain.cmakeI've noticed that the IOS_ARCH specified at the bottom is wrong, but removing those lines or adding arm64 to the platform IOS_ARCH doesn't fix the undefined symbols. Also most of the other options doesn't seem tha have an effect, I couldn't find out what results in the NEON definitions missing (see below).On a x86-64 Mac using:cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_ARCHITECTURES=arm64 \-DWEBP_BUILD_DWEBP=0 -DWEBP_BUILD_CWEBP=0 \-DWEBP_BUILD_IMG2WEBP=0 -DWEBP_BUILD_WEBPINFO=0 \-DWEBP_BUILD_WEBPMUX=0 -DWEBP_BUILD_EXTRAS=0will generate a libwebpdecoder.a with the correct symbols, even if I force the -simulator flag (-DIOS_PLATFORM=SIMULATOR wasn't recognized for me using cmake 3.20.5).That works for me on an arm64 Mac, too. I've compared the CMake output of this with my project and noticed the following in my output only:-- Performing Test WEBP_HAVE_FLAG_NEON - Failed
So there's some flags or settings that make this test fail. Regardless of the test, shouldn't it still work? As you said the files add stub definitions for those functions when NEON support isn't available.After digging in the CMake sources I found that those files will be removed if the check failed (or WEBP_ENABLE_SIMD is set to OFF). The header will still add the declarations if __aarch64__ is set, resulting in those undefined references.I've added a patch which no longer removes SIMD files from the generated CMake project, even if SIMD is disabled or unavailable, so that the stub definitions are added either way. Is this the right approach?
After my change to better handle the values in config.h [1] this shouldn't be necessary, though it still might be a reasonable clean up. An open issue after my change is that the cmake build was not designed with multi-configuration in mind, so the simulators will use C-code only when they could instead use some of the optimizations. Because all of the device targets are arm, however, it won't be a problem in that case.