The LuaJIT maintainer is missing that Apple does not claim any conformance to ARM EABI. Apple's ABI is defined to be based on the AAPCS standard, but Apple makes no claims to it being exact.
In other words, it's not Linux, and it sounds like the LuaJIT maintainer is annoyed that it doesn't follow a common approach used on Linux.
Anyone that works on low-level implementations that sit below the standard platform compiler should expect this kind of thing when supporting multiple platforms.
Apple's ABI for iOS is a custom derivative of APCS, not AAPCS. They do not even try to conform to the AAPCS ABI, nor should they need to. iOS has a soft-float ABI, but uses the float glue names from libgcc, not the EABI names.
This whole thing reads like the LuaJIT guy whining that he has to do some work to port to iOS. The compiler-rt library provides these functions and it shouldn't take him more than 10 minutes to figure out the proper names to use on iOS.
That doesn't mean that ohmantics here doesn't have a good point (that it's not realistic to assume that porting to the different platforms doesn't involve some work specific to the platform) and gives the precise information where the soft-float functions on iOS can be found.
I can also understand Mike too that he didn't want to spend the time on that port (I think, because iOS doesn't allow apps any Jiting, thereby limiting the power of LuaJit on iOS). Still the information that ohmantics gives regarding compiler-rt library can help us obtain a balanced view.
In other words, it's not Linux, and it sounds like the LuaJIT maintainer is annoyed that it doesn't follow a common approach used on Linux.
Anyone that works on low-level implementations that sit below the standard platform compiler should expect this kind of thing when supporting multiple platforms.
Source: http://developer.apple.com/library/ios/#documentation/Xcode/...