Luajit package has been recently updated to the latest commit in the
master branch [1]. But we discovered several problems:
- LUAJIT_VERSION doesn't contain the luajit version anymore but a commit hash
- With Luajit, luvi doesn't work without rng support enabled.
- Building for 64-bit target requires a 64-bit host for all target platform
- luajit and host-luajit needs to be built with the same option, so the
bytecode generated by host-luajit is valid on luajit.
- iteration with pairs() does not result in the same order since luajit 2.1.
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/1710552605
Best regards,
Romain
Francois Perrad (1):
package/luajit: disable 64 bit GC objects
Romain Naour (5):
package/luvi: don't use LUAJIT_VERSION for the luajit installation
path
support/testing: test_luvi: switch to armv5 to boot with rng support
enabled
package/luajit: rework BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS
package/luajit: building for 64-bit target requires a 64-bit host for
all platform
support/testing: test_luvi: make luvi test reproducible
package/luajit/Config.in | 12 +++++++-----
package/luajit/luajit.mk | 2 ++
package/luvi/luvi.mk | 8 ++++++--
support/testing/tests/package/test_luvi.py | 12 ++++++------
4 files changed, 21 insertions(+), 13 deletions(-)
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
Luajit package has been recently updated to the latest commit in the
master branch [1]. Since then LUAJIT_VERSION doesn't contain the luajit
version anymore but a commit hash:
LUAJIT_VERSION = 05f1984e1a862e4b3d3c3b370c773492e2edf84a
Use pkg-config --variable=version luajit in luvi package to set
LUA_PATH correctly.
Fixes:
luajit: unknown luaJIT command or jit.* modules not installed
https://gitlab.com/buildroot.org/buildroot/-/jobs/1710552605
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
Signed-off-by: Romain Naour <redacted>
Cc: Jörg Krause <redacted>
Tested-by: Jörg Krause <redacted>
Acked-by: Francois Perrad <redacted>
---
The TestLuvi doesn't work yet due to missing rng support on Qemu armv7 target
used to run the test. luvi -v is stuck due to getrandom().
---
package/luvi/luvi.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gzLUVI_SITE=https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)LUVI_LICENSE=Apache-2.0LUVI_LICENSE_FILES=LICENSE.txt-LUVI_DEPENDENCIES=libuvluajitluvhost-luajit+LUVI_DEPENDENCIES=libuvluajitluvhost-luajithost-pkgconf# Dispatch all architectures of LuaJITifeq ($(BR2_i386),y)
@@ -30,12 +30,16 @@ elseLUVI_TARGET_ARCH=$(BR2_ARCH)endif+# LUAJIT_VERSION and the luajit installation path may not use the+# same value. Use the value from luajit.pc file.+LUVI_LUAJIT_VERSION=$(shell$(PKG_CONFIG_HOST_BINARY)--variable=versionluajit)+# Bundled lua bindings have to be linked statically into the luvi executableLUVI_CONF_OPTS=\-DBUILD_SHARED_LIBS=OFF\-DWithSharedLibluv=ON\-DTARGET_ARCH=$(LUVI_TARGET_ARCH)\--DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUAJIT_VERSION)/?.lua+-DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUVI_LUAJIT_VERSION)/?.lua# Add "rex" module (PCRE via bundled lrexlib)ifeq ($(BR2_PACKAGE_PCRE),y)
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
Since the commit replacing moonjit by luajit [1] luvi doesn't work without
rng support enabled.
Switch to armv5 to use virtio-rng-pci on the qemu command line [2].
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
[2] https://git.buildroot.net/buildroot/tree/support/testing/infra/emulator.py?h=2021.08.1
Signed-off-by: Romain Naour <redacted>
Cc: Jörg Krause <redacted>
---
luvi still doesn't work since the luv static linking doesn't seems to
work anymore.
(see https://github.com/luvit/luvi/commit/a9dc8dae2eb69d4a754a0cf5c08622d70f6b7067)
# luvi -v
[string "return require('init')(...)"]:1: module 'init' not found:
no field package.preload['init']
no file './init.lua'
no file '/usr/share/luajit-2.1.0-beta3/init.lua'
no file '/usr/local/share/lua/5.1/init.lua'
no file '/usr/local/share/lua/5.1/init/init.lua'
no file '/usr/share/lua/5.1/init.lua'
no file '/usr/share/lua/5.1/init/init.lua'
no file './init.so'
no file '/usr/local/lib/lua/5.1/init.so'
no file '/usr/lib/lua/5.1/init.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
[string "return require('init')(...)"]:1: in main chunk
luvi now try to load init.lua script:
https://github.com/luvit/luvi/blob/v2.12.0/src/main.c#L176
Reverting to moonjit fixes the issue.
---
support/testing/tests/package/test_luvi.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -1,10 +1,10 @@configBR2_PACKAGE_LUAJIT_ARCH_SUPPORTSbool-defaultyifBR2_i386||\-(BR2_x86_64&&BR2_HOSTARCH='x86_64')||\-BR2_powerpc||BR2_arm||BR2_armeb||BR2_aarch64||\-((BR2_mips||BR2_mipsel)&&!BR2_MIPS_SOFT_FLOAT&&\-!BR2_MIPS_CPU_MIPS32R6&&!BR2_MIPS_CPU_MIPS64R6)+defaultyifBR2_arm||BR2_armeb||BR2_aarch64+defaultyifBR2_i386||(BR2_x86_64&&BR2_HOSTARCH='x86_64')+defaultyifBR2_powerpc+defaultyif(BR2_mips||BR2_mipsel)&&!BR2_MIPS_SOFT_FLOAT\+&&!BR2_MIPS_CPU_MIPS32R6&&!BR2_MIPS_CPU_MIPS64R6# -m32 flag is used for 32bit builds and host-luajit has# limited architecture supportdepends onBR2_HOSTARCH="x86_64"||BR2_HOSTARCH="x86"
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
Currently only x86_64 target requires a 64-bit host but building
aarch64 target with a 32-bit host is allowed.
This constraint is for all architectures [1].
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/628301.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Yann E. MORIN <redacted>
---
package/luajit/Config.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -1,13 +1,15 @@configBR2_PACKAGE_LUAJIT_ARCH_SUPPORTSbooldefaultyifBR2_arm||BR2_armeb||BR2_aarch64-defaultyifBR2_i386||(BR2_x86_64&&BR2_HOSTARCH='x86_64')+defaultyifBR2_i386||BR2_x86_64defaultyifBR2_powerpcdefaultyif(BR2_mips||BR2_mipsel)&&!BR2_MIPS_SOFT_FLOAT\&&!BR2_MIPS_CPU_MIPS32R6&&!BR2_MIPS_CPU_MIPS64R6# -m32 flag is used for 32bit builds and host-luajit has# limited architecture supportdepends onBR2_HOSTARCH="x86_64"||BR2_HOSTARCH="x86"+# Building for 64-bit target requires a 64-bit host+depends on!BR2_ARCH_IS_64||BR_HOST_ARCH="x86_64"configBR2_PACKAGE_LUAJITbool"luajit"
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
As explained by Jörg [1], iteration with pairs() does not result in the
same order since luajit 2.1.
From [2]
"Table iteration with pairs() does not result in the same order?
The order of table iteration is explicitly undefined by the Lua
language standard. Different Lua implementations or versions may use
different orders for otherwise identical tables. Different ways of
constructing a table may result in different orders, too. Due to
improved VM security, LuaJIT 2.1 may even use a different order on
separate VM invocations or when string keys are newly interned.
If your program relies on a deterministic order, it has a bug.
Rewrite it, so it doesn't rely on the key order.
Or sort the table keys, if you must."
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/627938.html
[2] https://luajit.org/faq.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Jörg Krause <redacted>
---
support/testing/tests/package/test_luvi.py | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
From: Francois Perrad <redacted>
Luvi uses the cross bytecode generation of host-luajit
the bytecode format has 2 flavors, depending of GC64 option.
Since the commit https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32aad79b7ea8ea6b78ed25
GC64 mode is enable by default on all 64bits platform.
With this patch, luajit and host-luajit are built with the same option,
so the bytecode generated by host-luajit is valid on luajit.
Signed-off-by: Francois Perrad <redacted>
[Romain:
- update commit title
- add a comment about missing LUAJIT_ENABLE_GC64]
Signed-off-by: Romain Naour <redacted>
---
The luvi test still doesn't works all the time since the output of
"luvi -v" is not reproducible
---
package/luajit/luajit.mk | 2 ++
1 file changed, 2 insertions(+)
@@ -26,8 +26,10 @@ endif# libraries are installed.ifeq ($(BR2_ARCH_IS_64),y)LUAJIT_HOST_CC=$(HOSTCC)+# There is no LUAJIT_ENABLE_GC64 option.elseLUAJIT_HOST_CC=$(HOSTCC)-m32+LUAJIT_XCFLAGS+=-DLUAJIT_DISABLE_GC64endif# We unfortunately can't use TARGET_CONFIGURE_OPTS, because the luajit
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
From: Yann E. MORIN <hidden> Date: 2021-11-12 12:52:35
Romain, All,
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted hunk
As explained by Jörg [1], iteration with pairs() does not result in the
same order since luajit 2.1.
From [2]
"Table iteration with pairs() does not result in the same order?
The order of table iteration is explicitly undefined by the Lua
language standard. Different Lua implementations or versions may use
different orders for otherwise identical tables. Different ways of
constructing a table may result in different orders, too. Due to
improved VM security, LuaJIT 2.1 may even use a different order on
separate VM invocations or when string keys are newly interned.
If your program relies on a deterministic order, it has a bug.
Rewrite it, so it doesn't rely on the key order.
Or sort the table keys, if you must."
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/627938.html
[2] https://luajit.org/faq.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Jörg Krause <redacted>
---
support/testing/tests/package/test_luvi.py | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):self.emulator.login()defversion_test(self):-cmd="luvi -v"+cmd="luvi -v | sort"
The issue with this is that, should 'luvi -v' fail, the command will not
fail, because of the pipe. Indeed, the result of a pipe is the result of
the right-most command, in this case 'sort', which I don't think would
ever fail in practice in this case.
So, to properly catch that 'luvi -v' fails, you would sort in the python
code, something like (assuming the luvi version alwas comes first?):
cmd = "luvi -v"
output, exit_code = self.emulator.run(cmd)
self.assertEqual(exit_code, 0)
self.assertIn('luvi', output[0])
output = sorted(output[1:])
self.assertIn('libuv', output[0])
self.assertIn('luvi', output[1])
self.assertIn('rex', output[2])
self.assertIn('ssl', output[3])
self.assertIn('zlib', output[4])
Regards,
Yann E. MORIN.
From: Yann E. MORIN <hidden> Date: 2021-11-12 12:56:18
Romain, All,
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted hunk
Currently only x86_64 target requires a 64-bit host but building
aarch64 target with a 32-bit host is allowed.
This constraint is for all architectures [1].
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/628301.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Yann E. MORIN <redacted>
---
package/luajit/Config.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
,^^^^^^^^^^^^
You removed that _________________________/
+ default y if BR2_i386 || BR2_x86_64
default y if BR2_powerpc
default y if (BR2_mips || BR2_mipsel) && !BR2_MIPS_SOFT_FLOAT \
&& !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
# -m32 flag is used for 32bit builds and host-luajit has
# limited architecture support
depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
+ # Building for 64-bit target requires a 64-bit host
+ depends on !BR2_ARCH_IS_64 || BR_HOST_ARCH="x86_64"
^^^^^^^^^^^^._____
\
... but you borked it when adding it back here _____/
You should not have blindly copy-pasted my poor code snippet from the
previous review! ;-]
Regards,
Yann E. MORIN.
From: Yann E. MORIN <hidden> Date: 2021-11-12 13:02:39
Romain, All,
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted hunk
Luajit package has been recently updated to the latest commit in the
master branch [1]. Since then LUAJIT_VERSION doesn't contain the luajit
version anymore but a commit hash:
LUAJIT_VERSION = 05f1984e1a862e4b3d3c3b370c773492e2edf84a
Use pkg-config --variable=version luajit in luvi package to set
LUA_PATH correctly.
Fixes:
luajit: unknown luaJIT command or jit.* modules not installed
https://gitlab.com/buildroot.org/buildroot/-/jobs/1710552605
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
Signed-off-by: Romain Naour <redacted>
Cc: Jörg Krause <redacted>
Tested-by: Jörg Krause <redacted>
Acked-by: Francois Perrad <redacted>
---
The TestLuvi doesn't work yet due to missing rng support on Qemu armv7 target
used to run the test. luvi -v is stuck due to getrandom().
---
package/luvi/luvi.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gzLUVI_SITE=https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)LUVI_LICENSE=Apache-2.0LUVI_LICENSE_FILES=LICENSE.txt-LUVI_DEPENDENCIES=libuvluajitluvhost-luajit+LUVI_DEPENDENCIES=libuvluajitluvhost-luajithost-pkgconf# Dispatch all architectures of LuaJITifeq ($(BR2_i386),y)
@@ -30,12 +30,16 @@ elseLUVI_TARGET_ARCH=$(BR2_ARCH)endif+# LUAJIT_VERSION and the luajit installation path may not use the+# same value. Use the value from luajit.pc file.+LUVI_LUAJIT_VERSION=$(shell$(PKG_CONFIG_HOST_BINARY)--variable=versionluajit)
I'm trying hard to get rid of calls to $(shell ) in variables, because
that emits spurious errors when calling printvars (see e.g. [0]):
$ make printvars VARS=LUVI_LUAJIT_VERSION
make[1]: [...]/host/bin/pkg-config: Command not found
LUVI_LUAJIT_VERSION=
Instead, could you try to use build-time shell expansion:
LUVI_LUAJIT_VERSION = `$(PKG_CONFIG_HOST_BINARY) --variable=version luajit`
[0] https://lore.kernel.org/buildroot/20211109165908.1942790-1-yann.morin.1998@free.fr/
Regards,
Yann E. MORIN.
# Bundled lua bindings have to be linked statically into the luvi executable
LUVI_CONF_OPTS = \
-DBUILD_SHARED_LIBS=OFF \
-DWithSharedLibluv=ON \
-DTARGET_ARCH=$(LUVI_TARGET_ARCH) \
- -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUAJIT_VERSION)/?.lua
+ -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUVI_LUAJIT_VERSION)/?.lua
# Add "rex" module (PCRE via bundled lrexlib)
ifeq ($(BR2_PACKAGE_PCRE),y)
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
From: Yann E. MORIN <hidden> Date: 2021-11-12 13:07:55
Romain, All,
I again hot "send" too fast; see a complement below...
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted hunk
Luajit package has been recently updated to the latest commit in the
master branch [1]. Since then LUAJIT_VERSION doesn't contain the luajit
version anymore but a commit hash:
LUAJIT_VERSION = 05f1984e1a862e4b3d3c3b370c773492e2edf84a
Use pkg-config --variable=version luajit in luvi package to set
LUA_PATH correctly.
Fixes:
luajit: unknown luaJIT command or jit.* modules not installed
https://gitlab.com/buildroot.org/buildroot/-/jobs/1710552605
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
Signed-off-by: Romain Naour <redacted>
Cc: Jörg Krause <redacted>
Tested-by: Jörg Krause <redacted>
Acked-by: Francois Perrad <redacted>
---
The TestLuvi doesn't work yet due to missing rng support on Qemu armv7 target
used to run the test. luvi -v is stuck due to getrandom().
---
package/luvi/luvi.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gzLUVI_SITE=https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)LUVI_LICENSE=Apache-2.0LUVI_LICENSE_FILES=LICENSE.txt-LUVI_DEPENDENCIES=libuvluajitluvhost-luajit+LUVI_DEPENDENCIES=libuvluajitluvhost-luajithost-pkgconf# Dispatch all architectures of LuaJITifeq ($(BR2_i386),y)
@@ -30,12 +30,16 @@ elseLUVI_TARGET_ARCH=$(BR2_ARCH)endif+# LUAJIT_VERSION and the luajit installation path may not use the+# same value. Use the value from luajit.pc file.+LUVI_LUAJIT_VERSION=$(shell$(PKG_CONFIG_HOST_BINARY)--variable=versionluajit)
Shouldn't that variable be set in luajit.mk, and that all packages that
need it use it?
Indeed the luajit version strgin is semantically the responsibility of
luajit, so it should be set in there.
Regards,
Yann E. MORIN.
# Bundled lua bindings have to be linked statically into the luvi executable
LUVI_CONF_OPTS = \
-DBUILD_SHARED_LIBS=OFF \
-DWithSharedLibluv=ON \
-DTARGET_ARCH=$(LUVI_TARGET_ARCH) \
- -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUAJIT_VERSION)/?.lua
+ -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUVI_LUAJIT_VERSION)/?.lua
# Add "rex" module (PCRE via bundled lrexlib)
ifeq ($(BR2_PACKAGE_PCRE),y)
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Yann,
Le 12/11/2021 à 13:51, Yann E. MORIN a écrit :
Romain, All,
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted
As explained by Jörg [1], iteration with pairs() does not result in the
same order since luajit 2.1.
From [2]
"Table iteration with pairs() does not result in the same order?
The order of table iteration is explicitly undefined by the Lua
language standard. Different Lua implementations or versions may use
different orders for otherwise identical tables. Different ways of
constructing a table may result in different orders, too. Due to
improved VM security, LuaJIT 2.1 may even use a different order on
separate VM invocations or when string keys are newly interned.
If your program relies on a deterministic order, it has a bug.
Rewrite it, so it doesn't rely on the key order.
Or sort the table keys, if you must."
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/627938.html
[2] https://luajit.org/faq.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Jörg Krause <redacted>
---
support/testing/tests/package/test_luvi.py | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):self.emulator.login()defversion_test(self):-cmd="luvi -v"+cmd="luvi -v | sort"
The issue with this is that, should 'luvi -v' fail, the command will not
fail, because of the pipe. Indeed, the result of a pipe is the result of
the right-most command, in this case 'sort', which I don't think would
ever fail in practice in this case.
So, to properly catch that 'luvi -v' fails, you would sort in the python
code, something like (assuming the luvi version alwas comes first?):
cmd = "luvi -v"
output, exit_code = self.emulator.run(cmd)
self.assertEqual(exit_code, 0)
I'm not sure it's really useful to test the error code of luvi -v since it
return 255 even on success :)
Hello Yann,
Le 12/11/2021 à 13:56, Yann E. MORIN a écrit :
Romain, All,
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted
Currently only x86_64 target requires a 64-bit host but building
aarch64 target with a 32-bit host is allowed.
This constraint is for all architectures [1].
[1] http://lists.busybox.net/pipermail/buildroot/2021-November/628301.html
Signed-off-by: Romain Naour <redacted>
Cc: Francois Perrad <redacted>
Cc: Yann E. MORIN <redacted>
---
package/luajit/Config.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
,^^^^^^^^^^^^
You removed that _________________________/
quoted
+ default y if BR2_i386 || BR2_x86_64
default y if BR2_powerpc
default y if (BR2_mips || BR2_mipsel) && !BR2_MIPS_SOFT_FLOAT \
&& !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
# -m32 flag is used for 32bit builds and host-luajit has
# limited architecture support
depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
+ # Building for 64-bit target requires a 64-bit host
+ depends on !BR2_ARCH_IS_64 || BR_HOST_ARCH="x86_64"
^^^^^^^^^^^^._____
\
... but you borked it when adding it back here _____/
You should not have blindly copy-pasted my poor code snippet from the
previous review! ;-]
Well, typo powered code snippet :p
Best regards,
Romain
Yann,
Le 12/11/2021 à 14:07, Yann E. MORIN a écrit :
Romain, All,
I again hot "send" too fast; see a complement below...
On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
quoted
Luajit package has been recently updated to the latest commit in the
master branch [1]. Since then LUAJIT_VERSION doesn't contain the luajit
version anymore but a commit hash:
LUAJIT_VERSION = 05f1984e1a862e4b3d3c3b370c773492e2edf84a
Use pkg-config --variable=version luajit in luvi package to set
LUA_PATH correctly.
Fixes:
luajit: unknown luaJIT command or jit.* modules not installed
https://gitlab.com/buildroot.org/buildroot/-/jobs/1710552605
[1] 9450b53c8e06f1b5a75840b82c0f4663a5d75c45
Signed-off-by: Romain Naour <redacted>
Cc: Jörg Krause <redacted>
Tested-by: Jörg Krause <redacted>
Acked-by: Francois Perrad <redacted>
---
The TestLuvi doesn't work yet due to missing rng support on Qemu armv7 target
used to run the test. luvi -v is stuck due to getrandom().
---
package/luvi/luvi.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gzLUVI_SITE=https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)LUVI_LICENSE=Apache-2.0LUVI_LICENSE_FILES=LICENSE.txt-LUVI_DEPENDENCIES=libuvluajitluvhost-luajit+LUVI_DEPENDENCIES=libuvluajitluvhost-luajithost-pkgconf# Dispatch all architectures of LuaJITifeq ($(BR2_i386),y)
@@ -30,12 +30,16 @@ elseLUVI_TARGET_ARCH=$(BR2_ARCH)endif+# LUAJIT_VERSION and the luajit installation path may not use the+# same value. Use the value from luajit.pc file.+LUVI_LUAJIT_VERSION=$(shell$(PKG_CONFIG_HOST_BINARY)--variable=versionluajit)
Shouldn't that variable be set in luajit.mk, and that all packages that
need it use it?
Indeed the luajit version strgin is semantically the responsibility of
luajit, so it should be set in there.
I'm not sure, because we need LUVI_LUAJIT_VERSION here because the luvi build
system is not able to retrieve the luajit version from pkg-config.
I'm not aware of any other package that provide two versions.
Something like ?
LUAJIT_VERSION = 05f1984e1a862e4b3d3c3b370c773492e2edf84a
LUAJIT_REAL_VERSION = 2.1.0-beta3
Best regards,
Romain
Regards,
Yann E. MORIN.
quoted
# Bundled lua bindings have to be linked statically into the luvi executable
LUVI_CONF_OPTS = \
-DBUILD_SHARED_LIBS=OFF \
-DWithSharedLibluv=ON \
-DTARGET_ARCH=$(LUVI_TARGET_ARCH) \
- -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUAJIT_VERSION)/?.lua
+ -DLUA_PATH=$(HOST_DIR)/share/luajit-$(LUVI_LUAJIT_VERSION)/?.lua
# Add "rex" module (PCRE via bundled lrexlib)
ifeq ($(BR2_PACKAGE_PCRE),y)
--
2.31.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot