[Buildroot] [PATCH 0/6] rework luvi test in gitlab after luajit version bump.

[Buildroot] [PATCH 0/6] rework luvi test in gitlab after luajit version bump.

[Romain Naour]

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

[Buildroot] [PATCH 1/6] package/luvi: don't use LUAJIT_VERSION for the luajit installation path

[Romain Naour]

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 <romain.naour@gmail.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Tested-by: Jörg Krause <joerg.krause@embedded.rocks>
Acked-by: Francois Perrad <francois.perrad@gadz.org>
---
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(-)

diff --git a/package/luvi/luvi.mk b/package/luvi/luvi.mk
index 386daafc31..ef5777cac8 100644
--- a/package/luvi/luvi.mk
+++ b/package/luvi/luvi.mk
@@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gz
 LUVI_SITE = https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)
 LUVI_LICENSE = Apache-2.0
 LUVI_LICENSE_FILES = LICENSE.txt
-LUVI_DEPENDENCIES = libuv luajit luv host-luajit
+LUVI_DEPENDENCIES = libuv luajit luv host-luajit host-pkgconf
 
 # Dispatch all architectures of LuaJIT
 ifeq ($(BR2_i386),y)
@@ -30,12 +30,16 @@ else
 LUVI_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=version luajit)
+
 # 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

Re: [Buildroot] [PATCH 1/6] package/luvi: don't use LUAJIT_VERSION for the luajit installation path

[Yann E. MORIN]

Romain, All,

On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
> 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 <romain.naour@gmail.com>
> Cc: Jörg Krause <joerg.krause@embedded.rocks>
> Tested-by: Jörg Krause <joerg.krause@embedded.rocks>
> Acked-by: Francois Perrad <francois.perrad@gadz.org>
> ---
> 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(-)
> 
> diff --git a/package/luvi/luvi.mk b/package/luvi/luvi.mk
> index 386daafc31..ef5777cac8 100644
> --- a/package/luvi/luvi.mk
> +++ b/package/luvi/luvi.mk
> @@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gz
>  LUVI_SITE = https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)
>  LUVI_LICENSE = Apache-2.0
>  LUVI_LICENSE_FILES = LICENSE.txt
> -LUVI_DEPENDENCIES = libuv luajit luv host-luajit
> +LUVI_DEPENDENCIES = libuv luajit luv host-luajit host-pkgconf
>  
>  # Dispatch all architectures of LuaJIT
>  ifeq ($(BR2_i386),y)
> @@ -30,12 +30,16 @@ else
>  LUVI_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=version luajit)

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

Re: [Buildroot] [PATCH 1/6] package/luvi: don't use LUAJIT_VERSION for the luajit installation path

[Yann E. MORIN]

Romain, All,

I again hot "send" too fast; see a complement below...

On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
> 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 <romain.naour@gmail.com>
> Cc: Jörg Krause <joerg.krause@embedded.rocks>
> Tested-by: Jörg Krause <joerg.krause@embedded.rocks>
> Acked-by: Francois Perrad <francois.perrad@gadz.org>
> ---
> 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(-)
> 
> diff --git a/package/luvi/luvi.mk b/package/luvi/luvi.mk
> index 386daafc31..ef5777cac8 100644
> --- a/package/luvi/luvi.mk
> +++ b/package/luvi/luvi.mk
> @@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gz
>  LUVI_SITE = https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)
>  LUVI_LICENSE = Apache-2.0
>  LUVI_LICENSE_FILES = LICENSE.txt
> -LUVI_DEPENDENCIES = libuv luajit luv host-luajit
> +LUVI_DEPENDENCIES = libuv luajit luv host-luajit host-pkgconf
>  
>  # Dispatch all architectures of LuaJIT
>  ifeq ($(BR2_i386),y)
> @@ -30,12 +30,16 @@ else
>  LUVI_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=version luajit)

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

Re: [Buildroot] [PATCH 1/6] package/luvi: don't use LUAJIT_VERSION for the luajit installation path

[Romain Naour]

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:
>> 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 <romain.naour@gmail.com>
>> Cc: Jörg Krause <joerg.krause@embedded.rocks>
>> Tested-by: Jörg Krause <joerg.krause@embedded.rocks>
>> Acked-by: Francois Perrad <francois.perrad@gadz.org>
>> ---
>> 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(-)
>>
>> diff --git a/package/luvi/luvi.mk b/package/luvi/luvi.mk
>> index 386daafc31..ef5777cac8 100644
>> --- a/package/luvi/luvi.mk
>> +++ b/package/luvi/luvi.mk
>> @@ -9,7 +9,7 @@ LUVI_SOURCE = luvi-src-v$(LUVI_VERSION).tar.gz
>>  LUVI_SITE = https://github.com/luvit/luvi/releases/download/v$(LUVI_VERSION)
>>  LUVI_LICENSE = Apache-2.0
>>  LUVI_LICENSE_FILES = LICENSE.txt
>> -LUVI_DEPENDENCIES = libuv luajit luv host-luajit
>> +LUVI_DEPENDENCIES = libuv luajit luv host-luajit host-pkgconf
>>  
>>  # Dispatch all architectures of LuaJIT
>>  ifeq ($(BR2_i386),y)
>> @@ -30,12 +30,16 @@ else
>>  LUVI_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=version luajit)
> 
> 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.
> 
>>  # 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
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/6] support/testing: test_luvi: switch to armv5 to boot with rng support enabled

[Romain Naour]

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 <romain.naour@gmail.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
---
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(-)

diff --git a/support/testing/tests/package/test_luvi.py b/support/testing/tests/package/test_luvi.py
index a85a6f4d27..eb15ad31b5 100644
--- a/support/testing/tests/package/test_luvi.py
+++ b/support/testing/tests/package/test_luvi.py
@@ -17,7 +17,7 @@ class TestLuvi(infra.basetest.BRTest):
 
     def login(self):
         cpio_file = os.path.join(self.builddir, "images", "rootfs.cpio")
-        self.emulator.boot(arch="armv7",
+        self.emulator.boot(arch="armv5",
                            kernel="builtin",
                            options=["-initrd", cpio_file])
         self.emulator.login()
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/6] package/luajit: rework BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS

[Romain Naour]

This commit reworks how BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS is
defined to follow the recommended syntax.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
---
 package/luajit/Config.in | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/package/luajit/Config.in b/package/luajit/Config.in
index e4e1249240..f6d01ed09a 100644
--- a/package/luajit/Config.in
+++ b/package/luajit/Config.in
@@ -1,10 +1,10 @@
 config BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS
 	bool
-	default y if BR2_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)
+	default y if BR2_arm || BR2_armeb || BR2_aarch64
+	default y if BR2_i386 || (BR2_x86_64 && BR2_HOSTARCH='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"
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/6] package/luajit: building for 64-bit target requires a 64-bit host for all platform

[Romain Naour]

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 <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
---
 package/luajit/Config.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/luajit/Config.in b/package/luajit/Config.in
index f6d01ed09a..bf98260c31 100644
--- a/package/luajit/Config.in
+++ b/package/luajit/Config.in
@@ -1,13 +1,15 @@
 config BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS
 	bool
 	default y if BR2_arm || BR2_armeb || BR2_aarch64
-	default y if BR2_i386 || (BR2_x86_64 && BR2_HOSTARCH='x86_64')
+	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"
 
 config BR2_PACKAGE_LUAJIT
 	bool "luajit"
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/6] package/luajit: building for 64-bit target requires a 64-bit host for all platform

[Yann E. MORIN]

Romain, All,

On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
> 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 <romain.naour@gmail.com>
> Cc: Francois Perrad <francois.perrad@gadz.org>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>  package/luajit/Config.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/package/luajit/Config.in b/package/luajit/Config.in
> index f6d01ed09a..bf98260c31 100644
> --- a/package/luajit/Config.in
> +++ b/package/luajit/Config.in
> @@ -1,13 +1,15 @@
>  config BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS
>  	bool
>  	default y if BR2_arm || BR2_armeb || BR2_aarch64
> -	default y if BR2_i386 || (BR2_x86_64 && BR2_HOSTARCH='x86_64')
                                           ,^^^^^^^^^^^^
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.

>  config BR2_PACKAGE_LUAJIT
>  	bool "luajit"
> -- 
> 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

Re: [Buildroot] [PATCH 4/6] package/luajit: building for 64-bit target requires a 64-bit host for all platform

[Romain Naour]

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:
>> 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 <romain.naour@gmail.com>
>> Cc: Francois Perrad <francois.perrad@gadz.org>
>> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
>> ---
>>  package/luajit/Config.in | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/package/luajit/Config.in b/package/luajit/Config.in
>> index f6d01ed09a..bf98260c31 100644
>> --- a/package/luajit/Config.in
>> +++ b/package/luajit/Config.in
>> @@ -1,13 +1,15 @@
>>  config BR2_PACKAGE_LUAJIT_ARCH_SUPPORTS
>>  	bool
>>  	default y if BR2_arm || BR2_armeb || BR2_aarch64
>> -	default y if BR2_i386 || (BR2_x86_64 && BR2_HOSTARCH='x86_64')
>                                            ,^^^^^^^^^^^^
> 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! ;-]

Well, typo powered code snippet :p

Best regards,
Romain

> 
> Regards,
> Yann E. MORIN.
> 
>>  config BR2_PACKAGE_LUAJIT
>>  	bool "luajit"
>> -- 
>> 2.31.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 5/6] package/luajit: disable 64 bit GC objects

[Romain Naour]

From: Francois Perrad <fperrad@gmail.com>

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 <francois.perrad@gadz.org>
[Romain:
  - update commit title
  - add a comment about missing LUAJIT_ENABLE_GC64]
Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
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(+)

diff --git a/package/luajit/luajit.mk b/package/luajit/luajit.mk
index fbbd8ebc70..89b164c96d 100644
--- a/package/luajit/luajit.mk
+++ b/package/luajit/luajit.mk
@@ -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.
 else
 LUAJIT_HOST_CC = $(HOSTCC) -m32
+LUAJIT_XCFLAGS += -DLUAJIT_DISABLE_GC64
 endif
 
 # 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

[Buildroot] [PATCH 6/6] support/testing: test_luvi: make luvi test reproducible

[Romain Naour]

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 <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
---
 support/testing/tests/package/test_luvi.py | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/support/testing/tests/package/test_luvi.py b/support/testing/tests/package/test_luvi.py
index eb15ad31b5..27155a75b6 100644
--- a/support/testing/tests/package/test_luvi.py
+++ b/support/testing/tests/package/test_luvi.py
@@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):
         self.emulator.login()
 
     def version_test(self):
-        cmd = "luvi -v"
+        cmd = "luvi -v | sort"
         output, exit_code = self.emulator.run(cmd)
-        self.assertIn('luvi', output[0])
-        self.assertIn('zlib', output[1])
+        self.assertIn('libuv', output[0])
+        self.assertIn('luvi', output[1])
         self.assertIn('rex', output[2])
-        self.assertIn('libuv', output[3])
-        self.assertIn('ssl', output[4])
+        self.assertIn('ssl', output[3])
+        self.assertIn('zlib', output[4])
 
     def test_run(self):
         self.login()
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 6/6] support/testing: test_luvi: make luvi test reproducible

[Yann E. MORIN]

Romain, All,

On 2021-11-12 12:00 +0100, Romain Naour spake thusly:
> 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 <romain.naour@gmail.com>
> Cc: Francois Perrad <francois.perrad@gadz.org>
> Cc: Jörg Krause <joerg.krause@embedded.rocks>
> ---
>  support/testing/tests/package/test_luvi.py | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/support/testing/tests/package/test_luvi.py b/support/testing/tests/package/test_luvi.py
> index eb15ad31b5..27155a75b6 100644
> --- a/support/testing/tests/package/test_luvi.py
> +++ b/support/testing/tests/package/test_luvi.py
> @@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):
>          self.emulator.login()
>  
>      def version_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.

>          output, exit_code = self.emulator.run(cmd)
> -        self.assertIn('luvi', output[0])
> -        self.assertIn('zlib', output[1])
> +        self.assertIn('libuv', output[0])
> +        self.assertIn('luvi', output[1])
>          self.assertIn('rex', output[2])
> -        self.assertIn('libuv', output[3])
> -        self.assertIn('ssl', output[4])
> +        self.assertIn('ssl', output[3])
> +        self.assertIn('zlib', output[4])
>  
>      def test_run(self):
>          self.login()
> -- 
> 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

Re: [Buildroot] [PATCH 6/6] support/testing: test_luvi: make luvi test reproducible

[Romain Naour]

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:
>> 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 <romain.naour@gmail.com>
>> Cc: Francois Perrad <francois.perrad@gadz.org>
>> Cc: Jörg Krause <joerg.krause@embedded.rocks>
>> ---
>>  support/testing/tests/package/test_luvi.py | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/support/testing/tests/package/test_luvi.py b/support/testing/tests/package/test_luvi.py
>> index eb15ad31b5..27155a75b6 100644
>> --- a/support/testing/tests/package/test_luvi.py
>> +++ b/support/testing/tests/package/test_luvi.py
>> @@ -23,13 +23,13 @@ class TestLuvi(infra.basetest.BRTest):
>>          self.emulator.login()
>>  
>>      def version_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 :)

>     self.assertIn('luvi', output[0])
>     output = sorted(output[1:])

As discussed on IRC, no need to drop output[0] since it's not the executed
command line.

Best regards,
Romain


>     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.
> 
>>          output, exit_code = self.emulator.run(cmd)
>> -        self.assertIn('luvi', output[0])
>> -        self.assertIn('zlib', output[1])
>> +        self.assertIn('libuv', output[0])
>> +        self.assertIn('luvi', output[1])
>>          self.assertIn('rex', output[2])
>> -        self.assertIn('libuv', output[3])
>> -        self.assertIn('ssl', output[4])
>> +        self.assertIn('ssl', output[3])
>> +        self.assertIn('zlib', output[4])
>>  
>>      def test_run(self):
>>          self.login()
>> -- 
>> 2.31.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot