macos – Lua在Mac OS X上编译脚本 – Intel vs PPC
多年来一直在Mac OS X通用二进制应用程序中使用Lua 5.0. Lua脚本使用luac编译,编译后的脚本与app捆绑在一起.他们在Tiger和Leopard,Intel或PPC中都能正常使用.
为了避免当时的库问题,我只是将Lua src树添加到我的Xcode项目中并按原样编译,没有任何问题. 是时候更新到更现代的Lua版本,所以我用5.1.4替换了源代码树.我使用make macosx重建了luac(机器在Intel上运行Leopard). 与往常一样,未编译的脚本在Tiger和Leopard,Intel和PPC中正常工作. 但是,现在编译的脚本无法在PPC计算机上加载. 所以我用’ansi’标志重建了luac,并重新编译了我的脚本.同样的错误.同样,’generic’的构建标志也没有产生任何乐趣. 谁能告诉我接下来能做些什么? 解决方法
Lua的编译脚本几乎是在短标题之后转储的原始字节码.头文件记录了用于编译字节码的平台的一些属性,但加载器仅验证当前平台具有相同的属性.
不幸的是,这会在加载在另一个平台上编译的字节码时产生问题,即使是由相同版本的Lua编译也是如此.当然,不能期望由不同版本的Lua编译的脚本工作,并且由于Lua的版本号包含在字节码头中,因此加载它们的尝试被核心捕获. 简单的答案是不编译脚本.如果Lua编译脚本本身,您只需要担心应用程序的各种版本中的Lua核心之间可能存在版本不匹配,这并不难解决. 实际上,支持已编译字节码的完全交叉兼容性是not easy.在该电子邮件中,Mike Pall确定了以下问题:
从我在邮件列表中看到的有关此问题的所有讨论中,我看到了两种可行的方法,假设您不愿意考虑只发送未编译的Lua脚本. 第一个是在加载编译脚本时修复字节顺序.事实证明这比你期望的更容易,因为它可以通过替换读取脚本文件的低级函数而不重新编译核心本身来完成.实际上,它甚至可以在纯Lua中完成,方法是将您自己的chunk reader函数提供给lua_load().只要您的平台上唯一的兼容性问题是字节顺序,这应该可以工作. 第二种是修补核心本身,以便在所有平台上使用编译脚本的通用表示.这已被描述为Luiz Henrique de Figueiredo:
就个人而言,我建议认真考虑不预先编译脚本,从而完全避免平台可移植性问题. 编辑:由于lhf的评论,我已经更新了我对字节码标题的描述.我还没有读过Lua源代码的这一部分,我可能应该先检查它,然后对标题中是否存在哪些信息非常自信. 这是来自 /* * make header */ void luaU_header (char* h) { int x=1; memcpy(h,LUA_SIGNATURE,sizeof(LUA_SIGNATURE)-1); h+=sizeof(LUA_SIGNATURE)-1; *h++=(char)LUAC_VERSION; *h++=(char)LUAC_FORMAT; *h++=(char)*(char*)&x; /* endianness */ *h++=(char)sizeof(int); *h++=(char)sizeof(size_t); *h++=(char)sizeof(Instruction); *h++=(char)sizeof(lua_Number); *h++=(char)(((lua_Number)0.5)==0); /* is lua_Number integral? */ } 可以看出,头部长度为12个字节并且包含签名(4个字节,“< esc> Lua”),版本和格式代码,用于字节序的标志字节,类型int的大小,size_t,指令和lua_Number,以及指示lua_Number是否为整数类型的标志. 这允许捕获大多数平台区别,但不会尝试捕获平台可以区别的各种方式. 我仍然支持上面提出的建议:首先,提供可编辑的来源;或者第二,定制ldump.c和lundump.c来存储和加载一个通用格式,另外注意任何自定义格式都应重新定义标题的LUAC_FORMAT字节,以免与stock字节码格式混淆. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |