-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error compiling for iOS arm64 from macOS arm64 #110
Comments
With OpenCV==4.6.0, error is slightly different (maybe a way to increase C standard?) Exception in file /Users/egor/dev/sw/src/sw/builder/command.cpp:840, function execute1: When executing: [org.sw.demo.mdadams.jasper-4.0.0]/jp2/jp2_enc.c
/Users/gregoire/.sw/storage/pkg/28/f5/b8d8/src/sdir/src/libjasper/jp2/jp2_enc.c:407:6: error: implicit declaration of function 'jpc_encode' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (jpc_encode(image, out, buf)) {
^
/Users/gregoire/.sw/storage/pkg/28/f5/b8d8/src/sdir/src/libjasper/jp2/jp2_enc.c:501:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
|
Could you share |
It is this file: https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake |
I've fixed arm64 build errors (and probably x64).
|
Your last error makes me think that you need to set the version of OpenCV to 4.6.0 in cmake list. If doesn't work, you can share with me the updated client/lib and I try to run it tomorrow. Thanks |
It is still current sw version. |
I suggest to try to build with latest packages for arm64/x64 first. After that we could try to build ios. |
Added Then (only -DPLATFORM is changed compared to above) /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/Applications/CLion.app/Contents/bin/ninja/mac/ninja -G Ninja -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DPLATFORM=MAC_ARM64 -S . -B cmake-build-release -DENABLE_BITCODE=FALSE
/opt/homebrew/bin/cmake --build cmake-build-release --config Release Produces gregoire@Gregoires-MBP-2 satoris-ocr % nm -g cmake-build-release/libsatoris_ocr.a | grep _ocr
cmake-build-release/libsatoris_ocr.a(process.cpp.o):
cmake-build-release/libsatoris_ocr.a(MRZBuilder.cpp.o):
cmake-build-release/libsatoris_ocr.a(ocr.cpp.o):
0000000000000674 T _ocr
0000000000000174 T _ocr_init
000000000000061c T _ocr_reset
0000000000000648 T _ocr_teardown So I guess is correct for Mac OS ARM64 Subsidiary question, where are the |
For some reason, after a build for Mac OS, the build for iOS works (the lib However, using all the
making me thing of a cache problem. |
Do you have a macbook to test (I think so seeing your command line output)? Do you want to test with me maybe? |
Yes, I have. |
Great, I thought I had, let me restart if unclear. You have access to git, on master branch of satoris-ocr.
Index: CMakeLists.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt (revision 6867c0f14816fae1bc35dde2c1ead42f53b070f9)
+++ b/CMakeLists.txt (date 1676447323899)
@@ -7,15 +7,15 @@
endif()
# set(CMAKE_CXX_FLAGS "-Wall -Wextra")
# set(CMAKE_CXX_FLAGS_DEBUG "-g")
-set(CMAKE_CXX_FLAGS_RELEASE "-O2")
+set(CMAKE_CXX_FLAGS_RELEASE "-O2 -fdeclspec")
# set(SW_DIR C:\\Users\\Ottunger\\.sw\\storage\\etc\\sw\\static)
set(SW_BUILD_SHARED_LIBS 0)
set(DEPENDENCIES
org.sw.demo.google.tesseract.libtesseract-5.2.0
- org.sw.demo.intel.opencv.videoio
- org.sw.demo.intel.opencv.imgcodecs
- org.sw.demo.intel.opencv.imgproc
+ org.sw.demo.intel.opencv.videoio-4.6.0
+ org.sw.demo.intel.opencv.imgcodecs-4.6.0
+ org.sw.demo.intel.opencv.imgproc-4.6.0
)
find_package(SW REQUIRED)
@@ -27,9 +27,9 @@
add_library(satoris_ocr STATIC process.cpp MRZBuilder.cpp ocr.cpp)
target_link_libraries(satoris_ocr ${DEPENDENCIES} iphlpapi.lib)
-add_library(satoris_ocr_shared SHARED process.cpp MRZBuilder.cpp ocr.cpp)
-set_target_properties(satoris_ocr_shared PROPERTIES PUBLIC_HEADER "ocr.h;ocr_type.h")
-target_link_libraries(satoris_ocr_shared ${DEPENDENCIES} iphlpapi.lib)
+#add_library(satoris_ocr_shared SHARED process.cpp MRZBuilder.cpp ocr.cpp)
+#set_target_properties(satoris_ocr_shared PROPERTIES PUBLIC_HEADER "ocr.h;ocr_type.h")
+#target_link_libraries(satoris_ocr_shared ${DEPENDENCIES} iphlpapi.lib)
-add_executable(satoris_ocr_exe main.cpp)
-target_link_libraries(satoris_ocr_exe org.sw.demo.intel.opencv.imgcodecs iphlpapi.lib)
+#add_executable(satoris_ocr_exe main.cpp)
+#target_link_libraries(satoris_ocr_exe org.sw.demo.intel.opencv.imgcodecs iphlpapi.lib) With this, I can compile for target macOS arm64 (using a host macOS arm64): /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/Applications/CLion.app/Contents/bin/ninja/mac/ninja -G Ninja -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DPLATFORM=MAC_ARM64 -S . -B cmake-build-release -DENABLE_BITCODE=FALSE
/opt/homebrew/bin/cmake --build cmake-build-release --config Release Once this build is successful, a build for iOS arm64 using /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/Applications/CLion.app/Contents/bin/ninja/mac/ninja -G Ninja -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DPLATFORM=OS64 -S . -B cmake-build-release -DENABLE_BITCODE=FALSE
/opt/homebrew/bin/cmake --build cmake-build-release --config Release Will work, but won't recompile the libraries folder (all libs under And so using them in an XCode build of an iOS app will yield the error above (fully:)
|
Can you upgrade opencv to the latest? I'm not in favor of fixing older packages. |
Done. You have to explicitely add sqlite as dep here.
Exact same result (at lib version difference): seems to build for macOS arm64 (but not sure if lib are macOS arm64 or macOS x64) then builds for iOS arm64 but definitely libs are not recompiled
|
By the way, only compiling "using sw" rather than "using cmake with sw as plugin" seems to produce arm64 libraries. The
But if I do a macOS only compilation: {
"name": "macos2macos",
"native": {
"stdlib": {
"c": null,
"compiler": null,
"kernel": null,
"cpp": null
}
},
"os": {
"arch": "aarch64",
"kernel": "com.Apple.Macos"
}
} sw build -settings-file macos2macos.json -sec --print-checks -wait-for-cc-checks -k 10 -sd -static
gregoire@Gregoires-MBP-2 satoris-ocr % lipo -info /Users/gregoire/.sw/storage/pkg/25/78/4a4d/obj/bld/175840/lib/liborg.sw.demo.mgk25.jbig.jbig-2.1.0.a
Non-fat file: /Users/gregoire/.sw/storage/pkg/25/78/4a4d/obj/bld/175840/lib/liborg.sw.demo.mgk25.jbig.jbig-2.1.0.a is architecture: arm64 I am not against using "sw directly" rather than cmake, we did it like this with |
To solve original issue (
I'm trying to implement sw ios build at the moment. Could you provide sw build command for your project? Is is just |
I don't really need the The command to build is |
Do you know how to run ios emulator? |
All the emulators I've seen for iOS are x86_64 so checking on them wouldn't work. (The answer of if I know is no). Maybe there exists simulator arm64 though. Running on a device is also an option, but you can only run signed programs and way more a mess than Android. |
I mean I need exactly ssh-like command. |
Yup that's what I had understood, and I'm quite afraid of how possible it is. My best bet is something like https://stackoverflow.com/a/39901796 but as you can see you will only push and run iOS apps that way. To have access to a shell on the device, I wonder if it would not be rooted... |
Good news, I maybe found a way on a simulator: xcrun simctl boot --arch=arm64 'iPhone 14 Pro' #Boot such a device, maybe need create once before
xcrun simctl spawn --arch=arm64 'iPhone 14 Pro' /bin/ls Media #Anything after device name is the command to run. The documentation of how to specify the executable:
I tried with a very simple program: #include <stdio.h>
int main() {return 2;} Then gregoire@Gregoires-MBP-2 ~ % gcc Downloads/main.c
gregoire@Gregoires-MBP-2 ~ % mv a.out Downloads
gregoire@Gregoires-MBP-2 ~ % ./Downloads/a.out
gregoire@Gregoires-MBP-2 ~ % echo $?
2
gregoire@Gregoires-MBP-2 ~ % xcrun simctl spawn --arch=arm64 'iPhone 14 Pro' /Users/gregoire/Downloads/a.out
gregoire@Gregoires-MBP-2 ~ % echo $?
2 So I think we can use that! |
Any chance I can help with setting up this? Let me know if I can be of service. Best |
I'll try to take a look at it over few days. |
Hi, any luck with this? Thanks, |
I was managed to build up to this point.
|
Probably you'll want to edit
Also I will see if I find something about thread-local. |
Probably you can try to compile using
|
Can you build it from sw sources? You need to copy checks for ios from macos checks manually at the moment. |
I'll see if I manage. So you use macOS checks and not results of running on iOS simulator? |
At the moment yes. I did not dig into running commands in the simulator. |
But running commands somewhere is already supported. You can do it yourself - write a script and pass to sw. |
I don't manage to build from sources to test myself for now, sadly...
|
OK, I could build from sources 🥳 I can build for macOS using
I created
But it fails pretty dramatically.
Am I missing something? |
As I said now copy macos checks into this 170209 checks directory. |
Same result afterwards |
Try simply Try to remove all checks, build for macos, then copy checks again, then build for ios. |
Ok, worked e2e
Let me see if I can use it in xcode |
Soooo all seems fine I can use the But it fails fot not finding the functions to link to.
And indeed in lib I have
Is it due to |
OK, I added
And I have no more linking errors to library anymore. More like:
This looks like stdc++ missing? |
Added |
Now to maybe make the checks automatic? Edit: I'm not sure the checks are correct for iOS, app crashes runtime for freeing too wide memory segments. |
If you need sw cmake integration, open sw cmake file and put there something like
Test it and I will add your changes to master branch. Automatic checks. Prepare bash script that will run passed program in ios emulator. |
Euh I don't need point 1 I think x) Will gladly do point 2, but I need more info what how these scripts are supposed to look like, you have examples and how to test? |
Well, I showed you API. You need a script that accepts program and its arguments. It executes it in the simulator, accepts input, returns stdout/err and error code.
How to test it? |
I think this is what you need (if you need stdout one more interpolation/echo couple may be needed, but this is the idea):
output at usage:
Not that the path to |
Morning, Read you, |
Hi, i resolved the find_package(jni REQUIRED)
if (JNI_FOUND)
message("Jni is found we got it include dir ${JNI_INCLUDE_DIRS}")
include_directories(${JNI_INCLUDE_DIRS})
message("Jni is found we got it library dir ${JNI_LIBRARIES}")
include_directories(${JNI_LIBRARIES})
endif(Jni_FOUND) |
Did you pull from git the project? |
Do you have crash call stacks? |
I mean, I get "regular" buffer overflows. |
What are "regular" overflows? |
OK, I think I found the problem with memory, I think it is indeed not related to |
I'm closing this as I can confirm my build is OK. |
Describe the bug
Linked to #100 : we've finalized months ago our build targetting android (on Windows, never got it to run on macOS) but I'd like to build for iOS now.
I'm therefore using the project https://github.com/leetal/ios-cmake to make an integration with XCode compiler into CMake. I've tested the build from both a bundled in CLion CMake and a complete separate CMake version. I use Ninja as XCode is not supported by sw.
The build fails as such (I see a
-platform x64
in there that I don't like):It has been configuerd without errors with
/opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/Applications/CLion.app/Contents/bin/ninja/mac/ninja -G Ninja -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DPLATFORM=OS64 -S . -B cmake-build-release -DENABLE_BITCODE=FALSE
Expected behavior
Build could create static libraries for import into an iOS project later.
To Reproduce
Steps to reproduce the behavior:
Information:
sw --version
output.Host: macOS 13.1, Apple M1 Pro arm64
Target: iOS 16.2, arm64
XCode 14.2 bundled compiler
-trace
parameter.The text was updated successfully, but these errors were encountered: