Re: LuaJIT on Buildroot
- From: François Perrad <francois.perrad@xxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 4 Jun 2012 20:39:45 +0200
2012/6/4 Mike Pall <mike-1206@xxxxxxxxxx>:
> François Perrad wrote:
>> I've posted a patch which adds LuaJIT in Buildroot (see
>> http://patchwork.ozlabs.org/patch/162404/).
>
> Umm, why do you patch the path in luaconf.h?
In fact, Buildroot already contains a package lua and some lua modules
like luasocket, luafilesystem.
In lua package, luaconf.h is patched (see
http://git.buildroot.net/buildroot/tree/package/lua/lua-root-path.patch).
The installation of all Lua modules is based on this patch.
So, I reproduce this patch in order to use/load the same Lua modules.
# lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require 'foo'
stdin:1: module 'foo' not found:
no field package.preload['foo']
no file './foo.lua'
no file '/usr/share/lua/foo.lua'
no file '/usr/share/lua/foo/init.lua'
no file '/usr/lib/lua/foo.lua'
no file '/usr/lib/lua/foo/init.lua'
no file './foo.so'
no file '/usr/lib/lua/foo.so'
no file '/usr/lib/lua/loadall.so'
stack traceback:
# luajit
LuaJIT 2.0.0-beta10 -- Copyright (C) 2005-2012 Mike Pall. http://luajit.org/
JIT: ON fold cse dce fwd dse narrow loop abc fuse
> require 'foo'
stdin:1: module 'foo' not found:
no field package.preload['foo']
no file './foo.lua'
no file '/usr/share/luajit-2.0.0-beta10/foo.lua'
no file '/usr/share/lua/foo.lua'
no file '/usr/share/lua/foo/init.lua'
no file '/usr/share/lua/5.1/foo.lua'
no file '/usr/share/lua/5.1/foo/init.lua'
no file './foo.so'
no file '/usr/lib/lua/foo.so'
no file '/usr/lib/lua/5.1/foo.so'
no file '/usr/lib/lua/loadall.so'
stack traceback:
>
> PREFIX is already doing this and it does it right: you need to
> have _both_ /usr/local/* and /usr/* in the path.
>
> The way you do it, you get /usr twice in the path.
>
>> 1) an external configuration of Large File Support (> 2Gb), because
>> usually with Buildroot
>> the toolchain is built without Large File Support
>
> Well, what happens if you don't remove the two defines?
see attached log.
if src/Makefile is patched like this :
-TARGET_XCFLAGS= -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U_FORTIFY_SOURCE
+TARGET_XCFLAGS= -U_FORTIFY_SOURCE
+ifndef _FILE_OFFSET_BITS
+TARGET_XCFLAGS+= -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
+endif
I could write :
ifneq ($(BR2_LARGEFILE),y)
LUAJIT_MFLAGS = _FILE_OFFSET_BITS=32
endif
define LUAJIT_BUILD_CMDS
$(MAKE) PREFIX="/usr" CROSS="$(TARGET_CROSS)" $(LUAJIT_MFLAGS) -C
$(@D)/src amalg
endef
>
> Doesn't it simply ignore the two defines and keep off_t a 32 bit
> integer? Because then everything would work as expected.
>
> [BTW: I don't think building without large file support would
> reduce the size of libc much. There's only a handful of calls
> affected and the kernel has 64 bit file offset support, anyway.]
a typical embedded system built with Buildroot has only 32 or 64 Mb of
RAM and Flash memory.
>
>> 2) a target 'uninstall' in order to define LUAJIT_UNINSTALL_STAGING_CMDS
>> and LUAJIT_UNINSTALL_TARGET_CMDS.
>
> Please try the attached patch. If it works for you as expected,
> I'll push it to git HEAD.
looks good.
>
> --Mike
Other related posts:
