BlocksKit for arm64 architecture

[matehat]

Hello,

I've been trying to build the library with the latest Xcode 5, targeting iOS 7 and the 3 new default architectures "arm7 arm7s arm64". When doing so, libffi compilation fails with a bunch of errors, in the likes of

In file included from /Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/src/debug.c:26:
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/include/ffi_common.h:77:1: error: unknown type name 'ffi_status'
ffi_status ffi_prep_cif_machdep(ffi_cif *cif);
^
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/include/ffi_common.h:77:33: error: unknown type name 'ffi_cif'
ffi_status ffi_prep_cif_machdep(ffi_cif *cif);
                                ^
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/include/ffi_common.h:78:1: error: unknown type name 'ffi_status'
ffi_status ffi_prep_cif_machdep_var(ffi_cif *cif,
^
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/include/ffi_common.h:78:37: error: unknown type name 'ffi_cif'
ffi_status ffi_prep_cif_machdep_var(ffi_cif *cif,
                                    ^
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/include/ffi_common.h:84:3: error: unknown type name 'ffi_cif'
  ffi_cif *cif;
  ^
/Users/mathieudamours/Development/storm/iOS/Uptime/Pods/libffi/ios/src/debug.c:50:20: error: unknown type name 'ffi_type'
void ffi_type_test(ffi_type *a, char *file, int line)
                   ^
6 errors generated.

When reverting to architectures "arm7 arm7s" it builds fine. Is that behavior expected?

[a2]

This is a problem with CocoaPods. This solution worked for me.

[matehat]

I'm sorry but it's really not the case. I'm not saying that the configurations are telling Xcode to not build for arm64, I'm saying when it tries to build for arm64 it fails with the above error. I had the same issue everyone had, the Pods was rejected as an implicit dependency for 'libPods.a' because its architectures 'armv7 armv7s' didn't contain all required architectures 'armv7 armv7s arm64' issue. That one gets fixed with the link you provide, but not the error I'm getting.

[zwaldowski]

libffi does not currently support AArch64 within the iOS sandbox. This is a developing situation.

[matehat]

OK, thanks for clearing that up!

[segiddins]

Any update on this?

[zwaldowski]

Not yet. No news on the end of libffi. We're awaiting the open-source release of the AArch64 7.0 runtime (opensource.apple.com) and we intend to investigate alternatives to libffi for this purpose.

[chasseurmic]

When you say that libffi does not currently support AArch64 within the iOS sandbox, you mean that on an actual device it actually works? Is this a problem tied to the Simulator only? Can an app without explicit support to armv7s ba submitted to the AppStore?

[zwaldowski]

No, the other way around. On device libffi currently supports only armv6, armv7, and armv7s.

[StevenMasini]

@zwaldowski Have you found any alternative to libffi ? Have you some news about Blockskit arm64 support ?

[pawelkata]

Any news on replacing libffi to suppory arm64?

[a2]

Nope. Apple still hasn't released the AArch64 7.0 runtime on their open source site.

[calimarkus]

@raff do you have plans for arm/64bit support for libffi?

[segiddins]

Do you have anyone at Apple you could get an ETA from?

[a2]

@segiddins Unfortunately not.

[segiddins]

@zwaldowski @a2 i noticed you pushed 2.0.0 onto master. Does this mean you have a fix for this coming soon?

[atgreen]

ARM/Linaro contributed base Aarch64 support to libffi for Linux a long time. What's the issue with iOS? The hard part is done, isn't it?

[zwaldowski]

@atgreen: Pure misconception on my part, I realize sheepishly. I assumed because the arm port required all that gentramp business it'd be a similar Act of Congress. However, in my initial tests, the AArch64 works perfectly with minimal changes. Pull request incoming.

[zvving]

What's time fix it?

[sarperdag]

Still no progress on this right?

[klaas]

any news? ;)

[zwaldowski]

The next branch has an experimental form of foreign-function interface with arm64 support. There are some edge cases with the Apple ARM64 platform it doesn't handle, but we're working on hashing those out.

[ericcastro]

any news on this ? it's been over a month :(

[zwaldowski]

Functionality is all there, and, again, is sitting in the next branch. Currently waiting on at atgreen/libffi#65.

[ericcastro]

I see. Since I'm using CocoaPods, what is the best approach to update to such branch ?

[zwaldowski]

pod 'BlocksKit', :git => 'https://github.com/pandamonia/BlocksKit.git', :branch => 'next'

Please let me know if there are any Pod integration issues.

[jameshays]

Methods are prefixed with bk_???

I understand the namespace game, but we took a beautiful api and turned it ugly.

On Jan 8, 2014, at 3:01 PM, Alexsander Akers notifications@github.com wrote:

As of v2.0 all methods are prefixed with "bk_". Did you try [-bk_initWithImage:style:handler][1] or [-bk_alertViewWithTitle:message:][2]?

[1] https://github.com/pandamonia/BlocksKit/blob/next/BlocksKit/UIKit/UIBarButtonItem%2BBlocksKit.h#L40
[2] https://github.com/pandamonia/BlocksKit/blob/next/BlocksKit/UIKit/UIAlertView%2BBlocksKit.h#L64

—
Reply to this email directly or view it on GitHub.

[zwaldowski]

I'm sorry you feel that way. Prefixed methods are the right thing to do, and some bizarre deprefixing system is not, particularly if your concern is code "beauty". I sincerely apologize for this inconvenience. Furthermore, this is not the place to discuss this particular issue, and is a tracking bug for BlocksKit on arm64.

[trevorsheridan]

Just backing up what @zwaldowski says. Prefixed methods are definitely the right approach when it comes to categories. Sorry to post this on this issue but I just felt the urge to chime in :)

[percysnoodle]

Is there a way to get the arm64 fixes without the prefixes?

[pawelkata]

@a2 yes, I did. Entering:

UIAlertView *alert = [UIAlertView bk_a(...)

autocompletes with:

bk_associateCopyOfValue...
bk_associatedValueForKey...
bk_associateValue...
bk_atomicallyAssiciateCopyOfValue...
bk_atomicallyAssociateValue...

No standard bk_alertViewWithTitle:message:

The problem persists on a fresh, empty project. I tried importing BlocksKit/BlocksKit.h, just BlocksKit.h in both pch and directly in .m file, but no cigar.

[matehat]

And if you import "BlocksKit+UIKit.h"?

[pawelkata]

@matehat you've just saved my day, friend! Works like a boss! :D

[AknEp]

I met compile error "Unterminated conditional directive" at "next" branch. ( commit #31b1d3dc97 )

my reproduction code is below :

https://github.com/AknEp/BugReproductionBlocksKit

my XCode screenshot below :

[pawelkata]

@AknEp this must be some recent stuff since I started having the same problem.

[AknEp]

Thanks.

Solved by set commit identifier manually.

pod 'BlocksKit', :git => 'https://github.com/pandamonia/BlocksKit.git', :commit => 'aa99a68674'

[haemi]

I try using

pod 'BlocksKit', :git => 'https://github.com/pandamonia/BlocksKit.git', :branch => 'next'

but still get

.../Pods/BlocksKit/ffi-mini/src/aarch64/ffi.c:422:41: Expected ';' after expression

What am I missing?

[zwaldowski]

Interesting. The appears to have been an upstream issue. Fixed in 9ff0ffb.

[pawelkata]

@zwaldowski just wanted to chime in and thank you for your tremendous support. BlocksKit is awesome :-)

[klundberg]

I've done these steps and am able to get things to build, but I get this warning when I do:

ld: warning: could not create compact unwind for _ffi_mini_call_unix64: does not use RBP or RSP based frame

Is this something to be concerned about? This only happens with debug builds; release builds don't seem to exhibit this but i'd like to eliminate all warnings all the time if possible :)

[zwaldowski]

@klundberg This is an issue with the Intel linker and the warning should be inhibited by -Wl,-no_compact_unwind. Can you check if your active target includes that for the linker flags or WARNING_LDFLAGS?

[klundberg]

Yes, WARNING_LDFLAGS is populated by cocoapods and my app target has those flags active.

[zwaldowski]

@klundberg Sorry for the slow response. It turns out it needed to be on OTHER_LDFLAGS and not WARNING_LDFLAGS as of a recent Xcode. This has been fixed in 95833bd.

[klundberg]

Awesome, thank you!

[OliverLetterer]

Any chance in seeing BlocksKit 2.1 now that arm64 has been merged into libffi?

[zwaldowski]

Yes, its release is imminent. Just going to make sure our KVO bugs are all fixed.

[zwaldowski]

Fixed in v2.2.0. Thanks, everyone.

[gilbert-jolly]

Thank you, Thank you a lot

[limbo-lab]

v2.2.0 works well, yet no long supports iOS5.0. is there a solution to this?