public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Russell Keith-Magee <russell@keith-magee.com>
To: "saleem gagguturu" <saleemgagguturu@live.com>,
	"libffi-discuss@sourceware.org" <libffi-discuss@sourceware.org>
Subject: Re: Cross compiling for iOS
Date: Tue, 28 May 2024 11:47:02 +0800	[thread overview]
Message-ID: <etPan.665553bb.75fc619f.6001@keith-magee.com> (raw)
In-Reply-To: <PU4P216MB209911D3A824B0A6D601290EC5F02@PU4P216MB2099.KORP216.PROD.OUTLOOK.COM>

[-- Attachment #1: Type: text/plain, Size: 4521 bytes --]

I’ve just done a quick test, and I didn’t have any difficulties building an iOS package for libFFI 3.4.6 with the tooling contained the cpython-apple-source-deps repository. Update the version number on line 49; comment out the patch application on line 479, and run `make libFFI-iOS` and build artefacts are generated.

Testing and releasing an updated package will require more work, and I don’t have time in my schedule to commit to that right now.

However, I would note that I’ve *never* published a *shared* iOS library - it’s only ever been a static build, because of the unusual requirements that iOS places on shared library distribution.

Yours,
Russ Magee %-)

On 27 May 2024 at 11:14:34 PM, saleem gagguturu (saleemgagguturu@live.com) wrote:

Hi Russell,
I just upgraded to the latest version of libffi 3.4.6.
I'm no longer able to compile the library as a shared library for ios.
In the configure logs, I'm getting this:

checking whether the xcrun -sdk iphoneos clang -target arm64-apple-ios linker (xcrun -sdk iphoneos ld -target arm64-apple-ios) supports shared libraries... no

The same log line shows "supports shared libraries... yes" in version 3.4.4.

Are you able to kindly check if you can build the 3.4.6 libraries and if so, upload them to your repo when you get the chance?

Thank very much in advance.
From: Russell Keith-Magee <russell@keith-magee.com>
Sent: Saturday, 3 February 2024 1:11 PM
To: saleem gagguturu <saleemgagguturu@live.com>; libffi-discuss@sourceware.org <libffi-discuss@sourceware.org>
Subject: Re: Cross compiling for iOS
 
I can’t speak to any of the eccentricities introduced by using OSX Cross, but the build process for iOS isn’t quite the same as it is for the platforms - it requires some pre- and post- processing. You don't just invoke ./configure from the command line as you would for a “normal” autoconf project.

There’s a `generate_darwin_source_and_headers.py` script in the root of the libffi code checkout; when you execute that, it generates `build_` folders for each architecture, and runs configure for you. 

You can see these tools in action in the repo I maintain for libFFI support on iOS/tvOS/watchOS; here’s the invocation of the helper script:
https://github.com/beeware/cpython-apple-source-deps/blob/main/Makefile#L474

And the build itself:
https://github.com/beeware/cpython-apple-source-deps/blob/main/Makefile#L339 

Each pass will give you a binary for a *single* ABI and architecture; Depending on your intended usage, you may need to combine them into  “fat” binaries for each ABI; depending on how you’re using the library, you may also need to combine the multiple ABI fat binaries into a single XCframework.

Or - the releases page for the repo I just linked has pre-built (single ABI and architecture) binaries.

https://github.com/beeware/cpython-apple-source-deps/releases/tag/libFFI-3.4.4-1

Hope that helps,
Russ Magee %-)

On 1 February 2024 at 3:04:54 pm, saleem gagguturu via Libffi-discuss (libffi-discuss@sourceware.org) wrote:

Hi,  

I'm trying to cross-compile libffi for iOS from Debian. I managed to cross-compile it successfully for MacOS (arm64 and x86) using OSX Cross but I'm getting some errors for iOS.  

My configure command is:  

./configure --host=arm-apple-darwin11 --prefix=$IOS_TOOLCHAIN_ROOT --libdir=$IOS_TOOLCHAIN_ROOT/lib --disable-docs  

This is the error I'm getting:  


libtool: link: ( cd ".libs" && rm -f "libffi_convenience.la" && ln -s "../libffi_convenience.la" "libffi_convenience.la" )  
Undefined symbols for architecture arm64:  
"_ffi_call", referenced from:  
_ffi_raw_call in raw_api.o  
_ffi_java_raw_call in java_raw_api.o  
"_ffi_closure_trampoline_table_page", referenced from:  
_ffi_closure_alloc in closures.o  
"_ffi_prep_cif_machdep", referenced from:  
_ffi_prep_cif_core in prep_cif.o  
"_ffi_prep_cif_machdep_var", referenced from:  
_ffi_prep_cif_core in prep_cif.o  
"_ffi_prep_closure_loc", referenced from:  
_ffi_prep_closure in prep_cif.o  
_ffi_prep_raw_closure_loc in raw_api.o  
_ffi_prep_raw_closure in raw_api.o  
_ffi_prep_java_raw_closure_loc in java_raw_api.o  
_ffi_prep_java_raw_closure in java_raw_api.o  
ld: symbol(s) not found for architecture arm64  

I've raised an issue with full logs here https://github.com/libffi/libffi/issues/821  

Anyone know any workaround for this? I need libffi as it's a dependency to Glib.  

Thanks  


  reply	other threads:[~2024-05-28  3:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01  7:04 saleem gagguturu
2024-02-03  2:11 ` Russell Keith-Magee
2024-05-27 15:14   ` saleem gagguturu
2024-05-28  3:47     ` Russell Keith-Magee [this message]
2024-05-28  6:18     ` Jeffrey Walton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=etPan.665553bb.75fc619f.6001@keith-magee.com \
    --to=russell@keith-magee.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=saleemgagguturu@live.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).