iOS Xcode support #15
Conversation
Added Xcode project that builds libffi like a normal iOS library This allows a user to add libffi as a subproject and should make integrating (and building) it much easier generate-ios-source-and-headers.py creates a shadow copy of the source tree and ifdefs files based on their architecture so your an compile everything for both targets and easily make a universal binary
|
Ok, done. Please check my work! Thanks, AG |
|
Thanks! It looks good. I'd like to find a more graceful solution for packaging libffi for iOS rather than just having to make a copy of the source tree with some ifdefs around each file. One option would be to not conditionally include files in the config and have the ifdefs built into every file instead of conditionally compiling the various source trees. The downside of this is that it would require a modification to every file. Hopefully having a build system that plays nicely with Xcode will obviate the need for something like fork libffi-ios. Also, would you like me to elaborate a bit more in the README on the iOS build instructions? |
|
README improvements are always welcome. Thanks! |
|
I second that, some documentation would be great ! While I had no problem with the previous build-ios.sh (using Xcode3 command line tools) script (as of libffi3.0.11-rc3), I'm not sure about how I'm supposed to use the new build system in place in libffi3.0.11-final. I'm under the impression that the new system does not produce universal 'fat' libraries any more ? The resulting libraries are left in Xcode DerivedData folder ? Am I mistaken ? |
|
That's true, the build system is more in line with other open source iOS projects. I guess there is a regression if not supporting Xcode 3 is a regression. To use the new version, one should add the project as a subproject in their app, and then it will work and build the appropriate library. |
|
The regression I mentioned is about 'free' halting my previously working program. In fact, the problem is seems to related to zwaldowski changes that linked dlmalloc.c in libffi, thus silently conflicting system malloc in my build. As for the new build system, as I cross-compile python, I don't have any xcode project but a configure/makefile. The new system does not easily allow me to write a script that can access the produced libffi.a - which is hidden somewhere in Xcode How hard would it be make some kind of install target in his project that would copy libffi.a in some known/configurable location ? In this case, I could simply build with |
|
I don't know if I have a good solution for the building problem. This stack overflow post explains a few options. You can still run xcodebuild with the generated files and it will output stuff in build/* Should dlmalloc not be included? |
Your link seems to be missing.
I'll give it a try when I get back to my Lion/Xcode4 machine. Right now, I tested with SnowLeopard/Xcode3 and your python script does not run (because of a python2.7 method call). I started a fork of libffi to try to fix things at my level.
My understanding is that |
|
I'm trying to work things out here, but I have a question about why you decided to change completely the build system ? What was your problem with the previous Wouldn't it have been possible to use this script in the Xcode project ? I'm not very comfortable with the Makefile being no more used. |
|
I think the decision was right. Most iOS people are likely to use Xcode, so a interworking with it helps. Is there a reason you cannot just build with xcodebuild -configuration CONFIGURATION_BUILD_DIR=mydir, collect the resulting .as and lipo them? And moving the discussion to one place would make it less confusing. :) |
|
In this comment, I'll try to answer to various comments about the xcodeproject usage, based on current HEAD.
I just tried this under Lion/Xcode4, and indeed, I cant find results in
That's fine, my mistake, I thought that the command line build did output in the same location as the gui build, but it's obviously not the case.
Thanks about the tip, as I've probably already said, I'm an Xcode newbie, and that's the kind of control I was looking for ! I found out that Knowing all this, I should be able to build libffi using command line and recreate the previously existing universal library.
I gave this a try in a simple standalone application project, I got the xcodeproj added, added libffi to the application target, this triggered the build of libffi when needed. The thing I couldn't figure was how to make Xcode find "ffi.h". Is Xcode supposed to find libffi include files automatically or not ? |
I'll try to elaborate about my concerns for the new Xcode project. First, I'm perfectly fine with the previous script being replaced by an Xcode project, as it seems to be possible to use My concern is that the Xcode project does not use the Makefile while the previous script did. As Xcode seems to provide 'External Build System' targets, or script running capabilities, I believe that is should be possible to create an Xcode project that would use the existing/validated build system (configure + make) that is used on all other platforms. As I already mentioned, I'm an Xcode newbie, so I may be missing something obvious. That why I asked mikelikespie why he chose to rewrite the build system using a python script instead or reusing previous elements. I tried to make a few experiments in a libffi fork and I got libffi building with Xcode3 using the makefile. This breaks when using Xcode4 but should be easy to fix. But as I'm no Xcode expert, I may be going in a wrong way. |
* added build script * Apply libffi-emscripten patch * Some changes to wasm32/ffi.c * Remove exit(0); from test suites * Fix LONGDOUBLE argument type * Use more macros in ffi.c * Use switch statements instead of if chains * Implemented struct args * Finish struct implementation * Partially working closures * Got closures working (most of closures test suite passes) * Revert changes to test suite * Update .gitignore * Apply code formatter * Use stackSave and stackRestore rather than directly adjusting stack pointer * Add missing break * Fix visibility of ffi_closure_alloc and ffi_closure_free * Fix FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used sig needs to be vi here for FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE, noticed this while running the test suite without WASM_BIGINT support. * Always use dynCall rather than direct wasmTable lookup (function pointer cast emulation changes dynCall) * Prevent closures.c from duplicating symbols * Try to set up CI * Add test with bigint * Make test methods static * Remove BigInt shorthand because it messes up terser * Add selenium tests * Update tests a bit to try to make CI work * WASM_BIGINT is a linker flag not a compile flag * Finish getting CI working (#1) * update gitignore * Avoid adding "use strict;" to generated JS This should be controlled by -s STRICT_JS in Emscripten. * Make JavaScript ES5 compliant * Remove redundant EXPORTED_RUNTIME_METHODS settings * Fix definition of DEREF_I16 * Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used * Add missing FFI_TYPE_STRUCT signature * Improve test scripts * Remove redundant EXPORTED_RUNTIME_METHODS settings * Add missing EOL * Add struct unpacking tests * Update ci config to try to actually use WASM_BIGINT * Revert "Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used" This reverts commit 61bd5a3. * Fix single_entry_structs tests * Fix return from closure call * Fix 64 bit return from closures * only allocate as much space on stack for return pointer as needed * Revert "only allocate as much space on stack for return pointer as needed" This reverts commit e54a30f. * xfail two tests * Fix err_bad_abi test * Remove test logging junk * Try to set up long double marshalling for closures * xfail err_bad_abi * Fix reference errors in previous commit * Add missing argument pointer assignment * Fix signature of function pointer in cls_dbls_struct * Fix longdouble argument * Try some changes to bigint handling * Fix BigInt handling * Fix cls_longdouble test * Fix long double closure arg with no WASM_BIGINT * Use EM_JS to factor out js helpers * Support for varargs closure calls * Fix varargs calls * Fix err_bad_abi test * Fix typo in previous commit * Add more assertions to closures test suite * Fix some asserts * Add assertions to a few more tests * Fix some tests * Fix more floating point assertions * Update more tests * Var args for ffi_call * Don't do node tests * Macro for allocating on stack * Add some comments, simplify struct handling * Try again to fix varargs calls, add comments * Consolidate WASM_BIGINT conditionals into LOAD_U64 and STORE_U64 macros * A bit of cleanup * Fix another typo * Some fixes to the testsuite * Another testsuite fix * Fix varags with closures? * Another attempt at getting closure varargs to work * sig is initialized later * Allow libffi.closures tests to be run * Improve build script * Remove redundant semicolons * Fix a few libffi.closures test failures * Cleanup * Legacy dynCall API is no longer used * Fix FFI_TYPE_LONGDOUBLE offset * xfail 2 tests for WASM - closure_loc_fn0; not applicable -- codeloc doesn't point to closure. - huge_struct; function signature too long. * Revert some redundant dg-output/printf statements Helps Node. * Revert "Don't do node tests" This reverts commit a341ef4. * Fix assertions in cls_24byte * More tiny formating fixes to test suite * Revert "Revert "Don't do node tests"" This reverts commit 7722e68. * Fix 64 bit returns when WASM_BIGINT is absent * Fix print statement in cls_24byte * Add CALL_FUNC_PTR macro to allow pyodide to define custom calling behavior to handle fpcast * Update single_entry_structs tests * More explanations * Fix compile error in last commit * Add more support for pyodide fpcast emulation, update CI to try to test it * Clone via https * Fix path to pyodide emsdk_env * Add asserts to the rest of the test suite * Fix test compile errors * Fix some tests * Fix cls_ulonglong * Fix alignment of <4 byte args * fix cls_ulonglong again * Use snprintf instead of sprintf * Should assert than strncmp returned 0 * Fix va_struct1 and va_struct3 * Change double and long double tests These tests are failing because of a strange bug with prinft and doubles, but I am not convinced it necessarily has anything to do with libffi. This version casts the double to int before printing it and avoids the issue * Enable node tests * Revert "Change double and long double tests" This reverts commit 8f3ff89. * Fix PYODIDE_FPCAST flag * add conftest.py back in * Fix emcc error: setting `EXPORTED_FUNCTIONS` expects `<class 'list'>` but got `<class 'str'>` See discussion on pyodide/pyodide#1596 * Remove test.html * Remove duplicate test file * More changes from upstream * Fix some whitespace * Add some basic debug logging statements * Reapply libffi.exp changes * Don't build docs (#7) Works around build issue makeinfo: command not found. * Update long double alignment Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting from `ChangeLog.md`: > The alignment of `long double`, which is a 128-bit floating-point > value implemented in software, is reduced from 16 to 8. The lower > alignment allows `max_align_t` to properly match the alignment we > use for malloc, which is 8 (raising malloc's alignment to achieve > correctness the other way would come with a performance regression). > (#10072) * Update long double alignment Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting from `ChangeLog.md`: > The alignment of `long double`, which is a 128-bit floating-point > value implemented in software, is reduced from 16 to 8. The lower > alignment allows `max_align_t` to properly match the alignment we > use for malloc, which is 8 (raising malloc's alignment to achieve > correctness the other way would come with a performance regression). > (#10072) * Improve error handling a bit (#8) * Fix handling of signed arguments to ffi_call (#11) * Fix struct argument handling in ffi_call (#10) * Remove fpcast emulation tests * Align the stack to MAX_ALIGN before making call (#12) * Increase MAX_ARGS * Cleanup (#14) * Fix Closure compiler error with -sASSERTIONS=1 (#15) * Remove function pointer cast emulation (#13) This reverts commit 593b402 and cbc54da, as it's no longer needed after PR pyodide/pyodide#2019. * Prefer the `__EMSCRIPTEN__` definition over `EMSCRIPTEN` (#18) "The preprocessor define EMSCRIPTEN is deprecated. Don't pass it to code in strict mode. Code should use the define __EMSCRIPTEN__ instead." https://github.com/emscripten-core/emscripten/blob/84a634167a1cd9e8c47d37a559688153a4ceace6/emcc.py#L887-L890 * Install autoconf 2.71 * Try again with installing autoconf 2.71 * Fix compatibility with Emscripten 3.1.28 * CI: remove use of `EM_CONFIG` env See commit: emscripten-core/emsdk@3d87d5e * Fix cls_multi_schar: cast rest_call to signed char * Remove test xfails (#17) * Fix long double when used as a varargs argument * Enable unwindtest and fix it * Add EM_JS_DEPS * Also require convertJsFunctionToWasm * Run tests very very verbose * Echo the .emscripten file * Remove --experimental-wasm-bigint insertion * Build with assertions * Move verbosity flags back out of LDFLAGS * Remove debug print statement * Use up to date pyodide docker image * Explicitly cast res_call to fix test failure * Put back name of main function in cls_longdouble_va.c * Fix alignment The stack pointer apparently needs to be aligned to 16. There were some terrible subtle bugs caused by not respecting this. stackAlloc knows that the stack should be 16 aligned, so we can use stackAlloc(0) to enforce this. This way if alignment requirements change, as long as Emscripten updates stackAlloc to continue to enforce them we should be okay. * Fix handling of systems with no Js bigint integration When we run the node tests we use node v14 tests (since node v14 is vendored with Emscripten). Node v14 has no Js bigint integration unless the --experimental-wasm-bigint flag is passed. So only the node tests really notice if we get this right. Turns out, it didn't work. We can't call a JavaScript function with 64 bit integer arguments without bigint integration. In ffi_call, we are trying to call a wasm function that takes 64 bit integer arguments. dynCall is designed to do this. We need to go back to tracking the signature when we don't have WASM_BIGINT, and then use dynCall. This works better now that emscripten can dynamically fill in extra dynCall wrappers: emscripten-core/emscripten#17328 On the other hand, for the closures we are not getting a function pointer as a first argument. We need to make our own wasm legalizer adaptor that splits 64 bit integer arguments and then calls the JavaScript trampoline, then the JavaScript trampoline reassembles them, calls the closure, then splits the result (if it's a 64 bit integer) and the adaptor puts it back together. * Improvements to emscripten test shell scripts (#21) This fixes the C++ unwinding tests and makes other minor improvements to the Emscripten test shell scripts. * Rename the test folder and move test files into emscripten test folder * Use docker image that has autoconf-2.71 * Cleanup * Pin emscripten 3.1.30 * Fix build.sh path * Rearrange ci pipeline * Fix bpo_38748 test * Cleanup * Improvements to comments, add static asserts, and update copyright * Use `*_js` instead of `*_helper` for EM_JS functions (#22) * Minor code simplification * Xfail first dejagnu test to work around emscripten cache messages See emscripten-core/emscripten#18607 * Remove unneeded xfails * Shorten conftest.py by using pytest-pyodide * Apply formatters and linters to emscripten directory * Fix Emscripten xfail hack * Fix build-tests script * Patch emscripten to quiet info messages * Clean up compiler flags in scripts and remove some settings from circleci config * Rename emscripten quiet script * Add missing export * Don't remove go.exp * Add reference to emscripten logging issue --------- Co-authored-by: Kleis Auke Wolthuizen <info@kleisauke.nl> Co-authored-by: Kleis Auke Wolthuizen <github@kleisauke.nl> Co-authored-by: Christian Heimes <christian@python.org>
Added Xcode project that builds libffi like a normal iOS library
This allows a user to add libffi as a subproject and should make
integrating
(and building) it much easier
generate-ios-source-and-headers.py creates a shadow copy of the source
tree and ifdefs files based on their architecture so your an compile
everything for both targets and easily make a universal binary