[PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation

[PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation

[Otavio Salvador]

We need full target passed for build so we changed the
rust-cross-canadian to use same code used in regular rust recipes and
added support to use specific llvm-target for the building host.

Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64 on x86_64")
Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
Fixes: 8ed000debb ("rust-common: Fix for target definitions returning 'NoneType' for arm")
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---

Changes in v2:
- Fix syntax for newer Python

 meta/recipes-devtools/rust/rust-common.inc    | 21 ++++++++++++------
 .../rust/rust-cross-canadian-common.inc       | 22 ++++++++++++++++---
 2 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..a937d58a37 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,12 +119,12 @@ def llvm_features(d):
 
 
 ## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-TARGET_ENDIAN[arm] = "little"
-TARGET_POINTER_WIDTH[arm] = "32"
-TARGET_C_INT_WIDTH[arm] = "32"
-MAX_ATOMIC_WIDTH[arm] = "64"
-FEATURES[arm] = "+v6,+vfp2"
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+TARGET_ENDIAN[arm-eabi] = "little"
+TARGET_POINTER_WIDTH[arm-eabi] = "32"
+TARGET_C_INT_WIDTH[arm-eabi] = "32"
+MAX_ATOMIC_WIDTH[arm-eabi] = "64"
+FEATURES[arm-eabi] = "+v6,+vfp2"
 
 ## armv7-unknown-linux-gnueabihf
 DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
@@ -304,12 +304,19 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""):
     else:
         arch_abi = rust_arch
 
+    # When building for the building system we need to return the HOST target
+    # or wrong flags are used.
+    if thing == "BUILD":
+        llvm_target = d.getVar('RUST_HOST_SYS', arch_abi)
+    else:
+        llvm_target = d.getVar('RUST_TARGET_SYS', arch_abi)
+
     features = features or d.getVarFlag('FEATURES', arch_abi) or ""
     features = features.strip()
 
     # build tspec
     tspec = {}
-    tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
+    tspec['llvm-target'] = llvm_target
     tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
     tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
     tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
diff --git a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
index 1f21c8af26..eff9212648 100644
--- a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
+++ b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
@@ -27,9 +27,23 @@ DEBUG_PREFIX_MAP = "-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDP
 
 python do_rust_gen_targets () {
     wd = d.getVar('WORKDIR') + '/targets/'
-    rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
-    rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
-    rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
+    # It is important 'TARGET' is last here so that it overrides our less
+    # informed choices for BUILD & HOST if TARGET happens to be the same as
+    # either of them.
+    for thing in ['BUILD', 'HOST', 'TARGET']:
+        bb.debug(1, "rust_gen_target for " + thing)
+        features = ""
+        cpu = "generic"
+        arch = d.getVar('{}_ARCH'.format(thing))
+        abi = ""
+        if thing is "TARGET":
+            abi = d.getVar('ABIEXTENSION')
+            # arm and armv7 have different targets in llvm
+            if arch == "arm" and target_is_armv7(d):
+                arch = 'armv7'
+            features = d.getVar('TARGET_LLVM_FEATURES') or ""
+            cpu = d.getVar('TARGET_LLVM_CPU')
+        rust_gen_target(d, thing, wd, features, cpu, arch, abi)
 }
 
 INHIBIT_DEFAULT_RUST_DEPS = "1"
@@ -45,6 +59,8 @@ python do_configure:prepend() {
     hosts = ["{}-unknown-linux-gnu".format(d.getVar("HOST_ARCH", True))]
 }
 
+INSANE_SKIP:${PN} = "libdir"
+
 INSANE_SKIP:${RUSTLIB_TARGET_PN} = "file-rdeps arch ldflags"
 SKIP_FILEDEPS:${RUSTLIB_TARGET_PN} = "1"
 
-- 
2.36.1

[PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---

(no changes since v1)

 .../cargo/cargo-cross-canadian.inc            | 20 ++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
index 7fc22a4128..01ba151d0a 100644
--- a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
+++ b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
@@ -39,6 +39,18 @@ do_compile:prepend () {
 	PKG_CONFIG_PATH="${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"
 }
 
+create_sdk_wrapper () {
+        file="$1"
+        shift
+
+        cat <<- EOF > "${file}"
+		#!/bin/sh
+		\$$1 \$@
+		EOF
+
+        chmod +x "$file"
+}
+
 do_install () {
     SYS_BINDIR=$(dirname ${D}${bindir})
     install -d "${SYS_BINDIR}"
@@ -47,6 +59,9 @@ do_install () {
 	chrpath -r "\$ORIGIN/../lib" ${i}
     done
 
+    # Uses SDK's CC as linker so linked binaries works out of box.
+    create_sdk_wrapper "${SYS_BINDIR}/target-rust-ccld" "CC"
+
     ENV_SETUP_DIR=${D}${base_prefix}/environment-setup.d
     mkdir "${ENV_SETUP_DIR}"
     ENV_SETUP_SH="${ENV_SETUP_DIR}/cargo.sh"
@@ -58,7 +73,10 @@ do_install () {
 		touch "\$CARGO_HOME/config"
 		echo "[build]" >> "\$CARGO_HOME/config"
 		echo 'target = "'${TARGET_SYS}'"' >> "\$CARGO_HOME/config"
-        fi
+		echo '# TARGET_SYS' >> "\$CARGO_HOME/config"
+		echo '[target.'${TARGET_SYS}']' >> "\$CARGO_HOME/config"
+		echo 'linker = "target-rust-ccld"' >> "\$CARGO_HOME/config"
+    fi
 
 	# Keep the below off as long as HTTP/2 is disabled.
 	export CARGO_HTTP_MULTIPLEXING=false
-- 
2.36.1

Re: [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation

[Sundeep KOKKONDA]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Hello Otavio,

Are there any build/test issues with previous implementation? Can you let me know what are the regression caused by below commits. I want to understand the reason for the changes in this patch.
Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64 on x86_64")
Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
Fixes: 8ed000debb ("rust-common: Fix for target definitions returning 'NoneType' for arm")

Thanks,
Sundeep K.

[-- Attachment #2: Type: text/html, Size: 614 bytes --]

Re: [OE-core] [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 5155 bytes --]


On 7/10/22 10:42, Otavio Salvador wrote:
> We need full target passed for build so we changed the
> rust-cross-canadian to use same code used in regular rust recipes and
> added support to use specific llvm-target for the building host.
>
> Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64 on x86_64")
> Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
> Fixes: 8ed000debb ("rust-common: Fix for target definitions returning 'NoneType' for arm")
> Signed-off-by: Otavio Salvador<otavio@ossystems.com.br>
> ---
>
> Changes in v2:
> - Fix syntax for newer Python
>
>   meta/recipes-devtools/rust/rust-common.inc    | 21 ++++++++++++------
>   .../rust/rust-cross-canadian-common.inc       | 22 ++++++++++++++++---
>   2 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc
> index ef70c48d0f..a937d58a37 100644
> --- a/meta/recipes-devtools/rust/rust-common.inc
> +++ b/meta/recipes-devtools/rust/rust-common.inc
> @@ -119,12 +119,12 @@ def llvm_features(d):
>   
>   
>   ## arm-unknown-linux-gnueabihf
> -DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
> -TARGET_ENDIAN[arm] = "little"
> -TARGET_POINTER_WIDTH[arm] = "32"
> -TARGET_C_INT_WIDTH[arm] = "32"
> -MAX_ATOMIC_WIDTH[arm] = "64"
> -FEATURES[arm] = "+v6,+vfp2"
> +DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
> +TARGET_ENDIAN[arm-eabi] = "little"
> +TARGET_POINTER_WIDTH[arm-eabi] = "32"
> +TARGET_C_INT_WIDTH[arm-eabi] = "32"
> +MAX_ATOMIC_WIDTH[arm-eabi] = "64"
> +FEATURES[arm-eabi] = "+v6,+vfp2"
>   
>   ## armv7-unknown-linux-gnueabihf
>   DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
> @@ -304,12 +304,19 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""):
>       else:
>           arch_abi = rust_arch
>   
> +    # When building for the building system we need to return the HOST target
> +    # or wrong flags are used.
> +    if thing == "BUILD":
> +        llvm_target = d.getVar('RUST_HOST_SYS', arch_abi)
> +    else:
> +        llvm_target = d.getVar('RUST_TARGET_SYS', arch_abi)
> +
>       features = features or d.getVarFlag('FEATURES', arch_abi) or ""
>       features = features.strip()
>   
>       # build tspec
>       tspec = {}
> -    tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
> +    tspec['llvm-target'] = llvm_target
>       tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
>       tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
>       tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
> diff --git a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
> index 1f21c8af26..eff9212648 100644
> --- a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
> +++ b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
> @@ -27,9 +27,23 @@ DEBUG_PREFIX_MAP = "-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDP
>   
>   python do_rust_gen_targets () {
>       wd = d.getVar('WORKDIR') + '/targets/'
> -    rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
> -    rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
> -    rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
> +    # It is important 'TARGET' is last here so that it overrides our less
> +    # informed choices for BUILD & HOST if TARGET happens to be the same as
> +    # either of them.
> +    for thing in ['BUILD', 'HOST', 'TARGET']:
> +        bb.debug(1, "rust_gen_target for " + thing)
> +        features = ""
> +        cpu = "generic"
> +        arch = d.getVar('{}_ARCH'.format(thing))
> +        abi = ""
> +        if thing is "TARGET":
> +            abi = d.getVar('ABIEXTENSION')
> +            # arm and armv7 have different targets in llvm
> +            if arch == "arm" and target_is_armv7(d):
> +                arch = 'armv7'
> +            features = d.getVar('TARGET_LLVM_FEATURES') or ""
> +            cpu = d.getVar('TARGET_LLVM_CPU')
> +        rust_gen_target(d, thing, wd, features, cpu, arch, abi)
>   }
>   
>   INHIBIT_DEFAULT_RUST_DEPS = "1"
> @@ -45,6 +59,8 @@ python do_configure:prepend() {
>       hosts = ["{}-unknown-linux-gnu".format(d.getVar("HOST_ARCH", True))]
>   }
>   
> +INSANE_SKIP:${PN} = "libdir"
> +
>   INSANE_SKIP:${RUSTLIB_TARGET_PN} = "file-rdeps arch ldflags"
>   SKIP_FILEDEPS:${RUSTLIB_TARGET_PN} = "1"


These look okay to me, could we backport these to Kirkstone?

Alejandro


>   
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#167848):https://lists.openembedded.org/g/openembedded-core/message/167848
> Mute This Topic:https://lists.openembedded.org/mt/92292890/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub  [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 6180 bytes --]

Re: [OE-core] [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Hello Alejandro,

Em qua., 13 de jul. de 2022 às 21:08, Alejandro Hernandez Samaniego <
alhe@linux.microsoft.com> escreveu:

> These look okay to me, could we backport these to Kirkstone?
>
This is my goal as well; kirkstone is broken for me at this moment.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 996 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
> 
> (no changes since v1)
> 
>  .../cargo/cargo-cross-canadian.inc            | 20 ++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)

I did look into this with some local testing. With:

SDKAMCHINE = "aarch64"
MACHINE = "qemuarm64"

bitbake rust-cross-canadian-aarch64

still fails so there is still something wrong with the SDK builds :/

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie <
richard.purdie@linuxfoundation.org> escreveu:

> On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > ---
> >
> > (no changes since v1)
> >
> >  .../cargo/cargo-cross-canadian.inc            | 20 ++++++++++++++++++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
>
> I did look into this with some local testing. With:
>
> SDKAMCHINE = "aarch64"
> MACHINE = "qemuarm64"
>
> bitbake rust-cross-canadian-aarch64
>
> still fails so there is still something wrong with the SDK builds :/
>

I'll check this. I didn't check this combination.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 1586 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote:
> 
> 
> Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > > ---
> > > 
> > > (no changes since v1)
> > > 
> > >   .../cargo/cargo-cross-canadian.inc            | 20
> > > ++++++++++++++++++-
> > >   1 file changed, 19 insertions(+), 1 deletion(-)
> > 
> > I did look into this with some local testing. With:
> > 
> > SDKAMCHINE = "aarch64"
> > MACHINE = "qemuarm64"
> > 
> > bitbake rust-cross-canadian-aarch64
> > 
> > still fails so there is still something wrong with the SDK builds
> > :/
> > 
> 
> 
> I'll check this. I didn't check this combination.

I tried an experiment to see which combinations worked. To do that I
added:

TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-${MACHINE}'

to the autobuilder config. This resulted in:

qemux86:
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491

buildtools:
https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885

beaglebone:
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563

edgerouter:
https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533

genericx86:
https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548

genericx86-64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533

multilib:
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554

pkgman-deb-non-deb:
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554

qemumips:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498
  
qemux86-64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487

qemuarm64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510

qemuarm:
https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525

so there is something rather wrong :(

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

Hello Richard and Khem

Em seg., 18 de jul. de 2022 às 12:59, Richard Purdie <
richard.purdie@linuxfoundation.org> escreveu:

> On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote:
> > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie
> > <richard.purdie@linuxfoundation.org> escreveu:
> > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > > SDKAMCHINE = "aarch64"
> > > MACHINE = "qemuarm64"
> > >
> > > bitbake rust-cross-canadian-aarch64
> > >
> > > still fails so there is still something wrong with the SDK builds
> > > :/
> > >
> >
> >
> > I'll check this. I didn't check this combination.
>
> I tried an experiment to see which combinations worked. To do that I
> added:
>
> TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-${MACHINE}'
>
> to the autobuilder config. This resulted in:
>
> qemux86:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491
>
> buildtools:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885
>
> beaglebone:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563
>
> edgerouter:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533
>
> genericx86:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548
>
> genericx86-64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533
>
> multilib:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554
>
> pkgman-deb-non-deb:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554
>
> qemumips:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498
>
> qemux86-64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487
>
> qemuarm64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510
>
> qemuarm:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525
>
> so there is something rather wrong :(
>

It does, indeed, but it doesn't seem related to this PR.

Do you know if this has worked?

I am asking as I did all development and testing using SDKMACHINE ?=
'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, looking
at some of the logs above, it seems it is using an SDKMACHINE as i686, so
this appears as a different issue for me.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 5027 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Mon, 2022-07-18 at 16:25 -0300, Otavio Salvador wrote:
> Hello Richard and Khem
> 
> Em seg., 18 de jul. de 2022 às 12:59, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote:
> > > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie
> > > <richard.purdie@linuxfoundation.org> escreveu:
> > > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> > > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > > > SDKAMCHINE = "aarch64"
> > > > MACHINE = "qemuarm64"
> > > > 
> > > > bitbake rust-cross-canadian-aarch64
> > > > 
> > > > still fails so there is still something wrong with the SDK
> > > > builds
> > > > :/
> > > > 
> > > 
> > > 
> > > I'll check this. I didn't check this combination.
> > 
> > I tried an experiment to see which combinations worked. To do that
> > I
> > added:
> > 
> > TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-
> > ${MACHINE}'
> > 
> > to the autobuilder config. This resulted in:
> > 
> > qemux86:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491
> > 
> > buildtools:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885
> > 
> > beaglebone:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563
> > 
> > edgerouter:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533
> > 
> > genericx86:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548
> > 
> > genericx86-64:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533
> > 
> > multilib:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554
> > 
> > pkgman-deb-non-deb:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554
> > 
> > qemumips:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498
> > 
> > qemux86-64:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487
> > 
> > qemuarm64:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510
> > 
> > qemuarm:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525
> > 
> > so there is something rather wrong :(
> > 
> 
> 
> It does, indeed, but it doesn't seem related to this PR. 
> 
> Do you know if this has worked?
> 
> I am asking as I did all development and testing using SDKMACHINE ?=
> 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However,
> looking at some of the logs above, it seems it is using an SDKMACHINE
> as i686, so this appears as a different issue for me.
> 

rust-cross-canadian hasn't officially worked properly or been
supported. In assessing whether a patch is better or worse, it is
useful to know which cases regress and which improve. I had hoped this
list of failures would be smaller. I will admit I don't know whether
this is better or worse than before so I guess that is the next thing I
need to determine.

What we don't know right now is which combinations work and which don't
so we can't even tell people what is expected to work and what
isn't/doesn't :(

I mentioned this report in case someone can work out the pattern, or
even better, understand what a fix looks like...

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie <
richard.purdie@linuxfoundation.org> escreveu:

> > It does, indeed, but it doesn't seem related to this PR.
> >
> > Do you know if this has worked?
> >
> > I am asking as I did all development and testing using SDKMACHINE ?=
> > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However,
> > looking at some of the logs above, it seems it is using an SDKMACHINE
> > as i686, so this appears as a different issue for me.
> >
>
> rust-cross-canadian hasn't officially worked properly or been
> supported. In assessing whether a patch is better or worse, it is
> useful to know which cases regress and which improve. I had hoped this
> list of failures would be smaller. I will admit I don't know whether
> this is better or worse than before so I guess that is the next thing I
> need to determine.
>

I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this worked.

What we don't know right now is which combinations work and which don't
> so we can't even tell people what is expected to work and what
> isn't/doesn't :(
>

See above.


> I mentioned this report in case someone can work out the pattern, or
> even better, understand what a fix looks like...
>

I am not familiar enough to Rust boostrap to help here but we spent a lot
of time to get the SDK working and I think this is a step on the right
direction, at least.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 2623 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote:
> Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > > It does, indeed, but it doesn't seem related to this PR. 
> > > 
> > > Do you know if this has worked?
> > > 
> > > I am asking as I did all development and testing using SDKMACHINE
> > > ?=
> > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine.
> > > However,
> > > looking at some of the logs above, it seems it is using an
> > > SDKMACHINE
> > > as i686, so this appears as a different issue for me.
> > > 
> > 
> > rust-cross-canadian hasn't officially worked properly or been
> > supported. In assessing whether a patch is better or worse, it is
> > useful to know which cases regress and which improve. I had hoped
> > this
> > list of failures would be smaller. I will admit I don't know
> > whether
> > this is better or worse than before so I guess that is the next
> > thing I
> > need to determine.
> > 
> 
> 
> I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this
> worked.
> 
> > What we don't know right now is which combinations work and which
> > don't
> > so we can't even tell people what is expected to work and what
> > isn't/doesn't :(
> > 
> 
> 
> See above.
>  
> > I mentioned this report in case someone can work out the pattern,
> > or
> > even better, understand what a fix looks like...
> > 
> 
> 
> I am not familiar enough to Rust boostrap to help here but we spent a
> lot of time to get the SDK working and I think this is a step on the
> right direction, at least.

Thanks, I do appreciate the patches. I think we've talked cross
purposes as I did report my aarch64 test case issue previously and I
thought this series was to attempt to fix things so the recipe did work
generically.

If I merge this to fix x86_64, I think people will then just ignore the
other cases and things will remain broken there which worries me a lot
and means we can't generically enable rust SDKs for the project and
gain autobuilder testing to spot future regressions.

Obviously you want your use case fixed though. I will try and evaluate
things a bit more tomorrow. What I don't want to do is merge a fix
which then makes it harder to get things correctly done in future
though, particularly when I know there will be an instant backport
request to an LTS as soon as I accept it for master.

We never should have accepted these rust cross-canadian recipes at all
as they are just broken :(.

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]

Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie <
richard.purdie@linuxfoundation.org> escreveu:

> On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote:
> > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie
> > <richard.purdie@linuxfoundation.org> escreveu:
> > > > It does, indeed, but it doesn't seem related to this PR.
> > > >
> > > > Do you know if this has worked?
> > > >
> > > > I am asking as I did all development and testing using SDKMACHINE
> > > > ?=
> > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine.
> > > > However,
> > > > looking at some of the logs above, it seems it is using an
> > > > SDKMACHINE
> > > > as i686, so this appears as a different issue for me.
> > > >
> > >
> > > rust-cross-canadian hasn't officially worked properly or been
> > > supported. In assessing whether a patch is better or worse, it is
> > > useful to know which cases regress and which improve. I had hoped
> > > this
> > > list of failures would be smaller. I will admit I don't know
> > > whether
> > > this is better or worse than before so I guess that is the next
> > > thing I
> > > need to determine.
> > >
> >
> >
> > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this
> > worked.
> >
> > > What we don't know right now is which combinations work and which
> > > don't
> > > so we can't even tell people what is expected to work and what
> > > isn't/doesn't :(
> > >
> >
> >
> > See above.
> >
> > > I mentioned this report in case someone can work out the pattern,
> > > or
> > > even better, understand what a fix looks like...
> > >
> >
> >
> > I am not familiar enough to Rust boostrap to help here but we spent a
> > lot of time to get the SDK working and I think this is a step on the
> > right direction, at least.
>
> Thanks, I do appreciate the patches. I think we've talked cross
> purposes as I did report my aarch64 test case issue previously and I
> thought this series was to attempt to fix things so the recipe did work
> generically.
>

I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise it was
using a different SDKMACHINE.

If I merge this to fix x86_64, I think people will then just ignore the
> other cases and things will remain broken there which worries me a lot
> and means we can't generically enable rust SDKs for the project and
> gain autobuilder testing to spot future regressions.
>

I understand.


> Obviously you want your use case fixed though. I will try and evaluate
> things a bit more tomorrow. What I don't want to do is merge a fix
> which then makes it harder to get things correctly done in future
> though, particularly when I know there will be an instant backport
> request to an LTS as soon as I accept it for master.
>

In fact I need patch 1/2 as this fixes our use case. We worked on 2/2 (this
patch) for completeness.


> We never should have accepted these rust cross-canadian recipes at all
> as they are just broken :(.
>

Agreed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 4827 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Mon, 2022-07-18 at 21:07 -0300, Otavio Salvador wrote:
> Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote:
> > > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie
> > > <richard.purdie@linuxfoundation.org> escreveu:
> > > > > It does, indeed, but it doesn't seem related to this PR. 
> > > > > 
> > > > > Do you know if this has worked?
> > > > > 
> > > > > I am asking as I did all development and testing
> > > > > using SDKMACHINE
> > > > > ?=
> > > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine.
> > > > > However,
> > > > > looking at some of the logs above, it seems it is using an
> > > > > SDKMACHINE
> > > > > as i686, so this appears as a different issue for me.
> > > > > 
> > > > 
> > > > rust-cross-canadian hasn't officially worked properly or been
> > > > supported. In assessing whether a patch is better or worse, it
> > > > is
> > > > useful to know which cases regress and which improve. I had
> > > > hoped
> > > > this
> > > > list of failures would be smaller. I will admit I don't know
> > > > whether
> > > > this is better or worse than before so I guess that is the next
> > > > thing I
> > > > need to determine.
> > > > 
> > > 
> > > 
> > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and
> > > this
> > > worked.
> > > 
> > > > What we don't know right now is which combinations work and
> > > > which
> > > > don't
> > > > so we can't even tell people what is expected to work and what
> > > > isn't/doesn't :(
> > > > 
> > > 
> > > 
> > > See above.
> > >  
> > > > I mentioned this report in case someone can work out the
> > > > pattern,
> > > > or
> > > > even better, understand what a fix looks like...
> > > > 
> > > 
> > > 
> > > I am not familiar enough to Rust boostrap to help here but we
> > > spent a
> > > lot of time to get the SDK working and I think this is a step on
> > > the
> > > right direction, at least.
> > 
> > Thanks, I do appreciate the patches. I think we've talked cross
> > purposes as I did report my aarch64 test case issue previously and
> > I
> > thought this series was to attempt to fix things so the recipe did
> > work
> > generically.
> > 
> 
> 
> I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise
> it was using a different SDKMACHINE.
> 
> > If I merge this to fix x86_64, I think people will then just ignore
> > the
> > other cases and things will remain broken there which worries me a
> > lot
> > and means we can't generically enable rust SDKs for the project and
> > gain autobuilder testing to spot future regressions.
> > 
> 
> 
> I understand.
>  
> > Obviously you want your use case fixed though. I will try and
> > evaluate
> > things a bit more tomorrow. What I don't want to do is merge a fix
> > which then makes it harder to get things correctly done in future
> > though, particularly when I know there will be an instant backport
> > request to an LTS as soon as I accept it for master.
> > 
> 
> 
> In fact I need patch 1/2 as this fixes our use case. We worked on 2/2
> (this patch) for completeness.
>  
> > We never should have accepted these rust cross-canadian recipes at
> > all
> > as they are just broken :(.
> 
> Agreed.
>  

I've done a bit more work on this and the more I dig, the more I think
we have some issues we need to sort with taking a step back and
checking some assumptions.

What I'm lacking is a good way to test the resulting rust toolchain.
Would someone with some rust knowledge be able to add something to
meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?

If someone can add some rust tests in the SDK, I think I might have an
idea of what the patches look like to properly fix the rust toolchain
there.

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie <
richard.purdie@linuxfoundation.org> escreveu:

> I've done a bit more work on this and the more I dig, the more I think
> we have some issues we need to sort with taking a step back and
> checking some assumptions.
>
> What I'm lacking is a good way to test the resulting rust toolchain.
> Would someone with some rust knowledge be able to add something to
> meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?
>
> If someone can add some rust tests in the SDK, I think I might have an
> idea of what the patches look like to properly fix the rust toolchain
> there.
>

Ok, I will send you a test case shortly.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie]

On Wed, 2022-07-20 at 15:11 -0300, Otavio Salvador wrote:
> 
> 
> Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > I've done a bit more work on this and the more I dig, the more I
> > think
> > we have some issues we need to sort with taking a step back and
> > checking some assumptions.
> > 
> > What I'm lacking is a good way to test the resulting rust
> > toolchain.
> > Would someone with some rust knowledge be able to add something to
> > meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?
> > 
> > If someone can add some rust tests in the SDK, I think I might have
> > an
> > idea of what the patches look like to properly fix the rust
> > toolchain
> > there.
> > 
> 
> 
> Ok, I will send you a test case shortly. 

Thanks.

Just to share what I'm thinking, I think we need to add a nativesdk to
llvm-rust like this:

diff --git a/meta/recipes-devtools/rust/rust-llvm.inc b/meta/recipes-devtools/rust/rust-llvm.inc
index 9baad12dc8e..625eb570416 100644
--- a/meta/recipes-devtools/rust/rust-llvm.inc
+++ b/meta/recipes-devtools/rust/rust-llvm.inc
@@ -47,6 +47,13 @@ EXTRA_OECMAKE:append:class-target = "\
     -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \
 "
 
+EXTRA_OECMAKE:append:class-nativesdk = "\
+    -DCMAKE_CROSSCOMPILING:BOOL=ON \
+    -DLLVM_BUILD_TOOLS=OFF \
+    -DLLVM_TABLEGEN=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-tblgen \
+    -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \
+"
+
 # The debug symbols are huge here (>2GB) so suppress them since they
 # provide almost no value. If you really need them then override this
 INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
@@ -68,4 +75,4 @@ FILES:${PN}-staticdev =+ "${libdir}/llvm-rust/*/*.a"
 FILES:${PN} += "${libdir}/libLLVM*.so.* ${libdir}/llvm-rust/lib/*.so.* ${libdir}/llvm-rust/bin"
 FILES:${PN}-dev += "${datadir}/llvm ${libdir}/llvm-rust/lib/*.so ${libdir}/llvm-rust/include ${libdir}/llvm-rust/share ${libdir}/llvm-rust/lib/cmake"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"

and then I think rust-cross-canadian can either copy in or create a
json file just like rust-cross does. Unlike gcc there is no target
specific cross compiler for rust as far as I can tell.

The crosssdk recipe also looks a bit suspect and I'm not sure that
entirely makes sense now or is needed. I guess it might be if we had
rust applications we needed to compile for the sdk itself but we don't
have any of those yet?

Cheers,

Richard

Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Otavio Salvador]

[-- Attachment #1.1: Type: text/plain, Size: 1051 bytes --]

Hello Richard,

Em qua., 20 de jul. de 2022 às 15:11, Otavio Salvador <
otavio@ossystems.com.br> escreveu:

> Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie <
> richard.purdie@linuxfoundation.org> escreveu:
>
>> I've done a bit more work on this and the more I dig, the more I think
>> we have some issues we need to sort with taking a step back and
>> checking some assumptions.
>>
>> What I'm lacking is a good way to test the resulting rust toolchain.
>> Would someone with some rust knowledge be able to add something to
>> meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?
>>
>> If someone can add some rust tests in the SDK, I think I might have an
>> idea of what the patches look like to properly fix the rust toolchain
>> there.
>>
>
> Ok, I will send you a test case shortly.
>

As promised. See attached.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #1.2: Type: text/html, Size: 1900 bytes --]

[-- Attachment #2: 0001-oeqa-sdk-rust-add-basic-cargo-test.patch --]
[-- Type: text/x-patch, Size: 2557 bytes --]

From d62112db3e4bc9ec9e3c7ca480ebf2f3a207e4a6 Mon Sep 17 00:00:00 2001
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Wed, 20 Jul 2022 16:06:01 -0300
Subject: [PATCH] oeqa: sdk: rust: add basic cargo test

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/lib/oeqa/sdk/cases/rust.py               | 31 +++++++++++++++++++
 meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml |  6 ++++
 .../lib/oeqa/sdk/files/rust/hello/src/main.rs |  3 ++
 3 files changed, 40 insertions(+)
 create mode 100644 meta/lib/oeqa/sdk/cases/rust.py
 create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
 create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/src/main.rs

diff --git a/meta/lib/oeqa/sdk/cases/rust.py b/meta/lib/oeqa/sdk/cases/rust.py
new file mode 100644
index 0000000000..c29b06223b
--- /dev/null
+++ b/meta/lib/oeqa/sdk/cases/rust.py
@@ -0,0 +1,31 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+import os
+import shutil
+import unittest
+
+from oeqa.core.utils.path import remove_safe
+from oeqa.sdk.case import OESDKTestCase
+
+from oeqa.utils.subprocesstweak import errors_have_output
+errors_have_output()
+
+class RustCompileTest(OESDKTestCase):
+    td_vars = ['MACHINE']
+
+    @classmethod
+    def setUpClass(self):
+        shutil.copytree(os.path.join(self.tc.sdk_files_dir, "rust/hello"),
+                        os.path.join(self.tc.sdk_dir, "hello"))
+
+    def setUp(self):
+        machine = self.td.get("MACHINE")
+        if not (self.tc.hasHostPackage("packagegroup-rust-cross-canadian-%s" % machine) or
+                self.tc.hasHostPackage("^rust-cross-canadian-", regex=True) or
+                self.tc.hasHostPackage("^cargo-cross-canadian-", regex=True)):
+            raise unittest.SkipTest("RustCompileTest class: SDK doesn't contain a Rust cross-canadian toolchain")
+
+    def test_cargo_build(self):
+        self._run('cd %s/hello; cargo build' % self.tc.sdk_dir)
diff --git a/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml b/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
new file mode 100644
index 0000000000..fe619478a6
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
@@ -0,0 +1,6 @@
+[package]
+name = "hello"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
diff --git a/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs b/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs
new file mode 100644
index 0000000000..a06c03f82a
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs
@@ -0,0 +1,3 @@
+fn main() {
+    println!("Hello, OpenEmbedded world!");
+}
-- 
2.36.1