Re: LuaJIT on Buildroot
- From: Mike Pall <mike-1206@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 5 Jun 2012 00:20:50 +0200
François Perrad wrote:
> 2012/6/4 Mike Pall <mike-1206@xxxxxxxxxx>:
> > 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.
Well, then the lua package should be fixed. The general distro
consensus is to add both /usr/local and /usr to the Lua paths.
The standard build options for LuaJIT follow that precedent.
Have a look at the Debian package:
http://packages.debian.org/unstable/interpreters/lua5.1
It's in the *-debian.tar.gz
> >> 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.
Ok, that's bad.
> 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
I've made a simpler fix: split-off the large-file support flags.
To disable LFS support, you can now pass TARGET_LFSFLAGS= to make.
Pushed to git HEAD.
> > [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.
That doesn't invalidate my point. You only save a couple of bytes
in a read-only (shared!) library, but break compatibility. That's
not a good deal. Someone might want to play a big video from a USB
stick. Not something unusual for an embedded system today.
> >> 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.
Pushed to git HEAD.
--Mike
Other related posts:
