Re: LuaJIT linker error on iOS

[Scott Shumaker <sshumaker@...>]

Do you expect to do a hardware fpu port at some point? I'd imagine it would be significantly less work than a whole new CPU family. (more interested in the performance 

Sent from my iPhone

On Feb 16, 2012, at 10:24 AM, Mike Pall <mikelu-1202@mike.de> wrote:

> Scott Shumaker wrote:
>> I'm including luajit in my iOS project (as a static library), and I
>> get the following linker errors:
>> 
>> Undefined symbols for architecture armv6:
>> "___aeabi_cdcmple", referenced from:
>> 
>> [...]
>> 
>> BTW, this is using iOS5.0.
> 
> Well, yes, this is a known problem. Some other users have written
> to me with the same issue. The iOS build of LuaJIT is broken for
> the latest XCode 4.2 (i.e. iOS 5.0). Or rather the Clang/LLVM
> version, that comes with it, is broken.
> 
> Those symbols are a mandatory part of the ARM EABI. They are
> needed by LuaJIT/ARM, because this is (still) a soft-float-only
> port. It uses soft-float function calls, even if you're compiling
> for a CPU which has a hardware FPU (VFP).
> 
> <rant> Apparently, some clever soul at Apple decided to strip
> those functions from Clang (and violate the ARM EABI). But hey,
> it's Apple and they define their own standards, anyway. And they
> truly love to break plenty of interesting stuff on every release.
> Building cross-platform apps that work on Apple's "lifestyle gear"
> ("hardware" sounds way too durable in comparison) is a nightmare
> and I'm lead to believe this is fully intentional. </rant>
> 
> Oh well, I don't have an easy solution for this. I've been working
> on this problem with someone, who helped me with the iOS port. We
> guessed those soft-float functions might still be present somewhere
> in the default libraries, except under different names (__divdf3
> etc.). But we didn't get around to figure out the details, yet.
> 
>> I appeared to have fixed it, I had to link against libgcc, which you
>> can find here:
>> 
>> /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/lib/gcc/arm-apple-darwin10/4.2.1
>> 
>> There's a couple different variants, depending on whether you're
>> building for armv6 or armv7.
> 
> Good to hear this fixes your problem! Alas, this is not a general
> solution, of course. I don't see an easy way to deduce the required
> library path and file name. Hardcoding these is certainly going to
> break on the next release of XCode and/or on previous releases.
> 
> --Mike
>