For 32 bit archictectures the luajit package needs a host compiler
able to generate 32 bit code using the "-m32" option so check if that
option is supported.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: François Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The basic rule for a package is to have its options named
after the package name. There is no reason this should not
also be the case for virtual packages.
Besides, this will allow us to switch luainterpreter to use the
soon-to-be-introduced virtual-package infrastructure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Mike Zick <minimod@morethan.org>
Cc: Francois Perrad <fperrad@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-Off-By: Paul Cercueil <paul@crapouillou.net>
Acked-By: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
the variable BUILDMODE does the job
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
the variable TARGET_STRIP does the job
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To install its shared library, the luajit Makefile does:
cd src && test -f $(FILE_SO) && \
$(INSTALL_X) $(FILE_SO) $(INSTALL_DYN) && \
$(LDCONFIG) $(INSTALL_LIB) && \
$(SYMLINK) $(INSTALL_SONAME) $(INSTALL_SHORT1) && \
$(SYMLINK) $(INSTALL_SONAME) $(INSTALL_SHORT2) || :
This means that if ldconfig doesn't work or isn't available on the
system, it won't create the libluajit-5.1.so -> libluajit-5.1.so.5.2.0
symbolic link.
Not having this symbolic link prevents lua-ev from finding the shared
version of the luajit library, and it fallbacks to using the
libluajit.a static library. However, this static library is not built
with -fPIC, so using it within a shared library doesn't work, and
leads to build failures on architectures that really do want to have
non-fPIC code into a shared library, such as x86-64.
By passing LDCONFIG=true during the installation steps of luajit, we
ensure that the symbolic links are created, which allows lua-ev to
detect the shared library properly, making everybody happy.
Investigation conducted with Samuel Martin. Thanks!
Fixes:
http://autobuild.buildroot.org/results/41c/41c8bb9cf91a86908a150dae27726136cb56f5b7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch introduces the luainterpreter virtual package, which
is provided either by 'lua' or by 'lua-jit'.
Packages that require a Lua interpreter can then depend on
BR2_PACKAGE_LUAINTERPRETER (in their Config.in) and luainterpreter
(in their .mk).
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
[yann.morin.1998@free.fr: switch to package-defined providers,
apply Thomas' comments]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The luajit amalgamation compile starts with building a host tool, and then
uses it to build itself. However, when CFLAGS is specified, as opposed to
TARGET_CFLAGS, then it is used for both HOST and TARGET builds. So if you
add something target specific into 'Target Optimizations' (for example,
'-mfpu=neon -mfloat-abi=softfp' for ARM Cortex-A8), then it gets into the
host tool compile, which then fails (because my build machine is not an
ARM Cortext-A8). This can be fixed by using TARGET_CFLAGS and
TARGET_LDFLAGS, instead of CFLAGS and LDFLAGS, respectively.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
