4 ms·
So is this just LLVM IR?
by ubercow 11y ago
So is this just LLVM IR?
- nekitamo 11y agoYep. I hope they leave this optional for iOS, as we use some proprietary libraries which we don't think the vendor will ship a new version of :(
- pgeorgi 11y agoYou may get by with a decompiler as laid out in http://llvm.org/devmtg/2013-04/bougacha-slides.pdf http://llvm.org/devmtg/2013-04/bougacha-slides.pdf And since you'll certainly not be the only one with that problem, Apple making it mandatory for iOS would probably spur development in that area.
- ponytech 11y agoI am not so confident : they now require that you ship a 64 bits version of your apps, which can be also be a problem if you use 32 bits only proprietary libraries.
- coob 11y agoThere's a good reason for that requirement. Loading 32bit apps on a 64but device requires loading all the 32bit version of shared libs, massively increasing the memory footprint.
- johntb86 11y agoI'm curious how that works. LLVM bitcode backwards/forwards compatibility is quite poor, from what I've heard. Will they fix some bitcode version to transmit, and have translators on the client/server sides? Have a bunch of different toolchain versions on the server side? Force everyone to resubmit with a newer version if they want to do any changes on the server side?
- joosters 11y agoPresumably the backwards/forwards compatibility is poor simply because people don't tend to have these files sitting around, they mostly exist (at the moment) as part of a compilation framework and are tempfiles. If needed, it wouldn't be too for someone with a few programmers (Apple could spare a few!) to write the proper versioning to upgrade/downgrade the file format as LLVM changes?