[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT linker error on iOS
- From: Scott Shumaker <sshumaker@...>
- Date: Thu, 16 Feb 2012 11:21:43 -0800
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 <firstname.lastname@example.org> 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:
>> 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.