* [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation
@ 2022-07-10 16:42 Otavio Salvador
2022-07-10 16:43 ` [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking Otavio Salvador
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Otavio Salvador @ 2022-07-10 16:42 UTC (permalink / raw)
To: openembedded-core; +Cc: 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-10 16:42 [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Otavio Salvador
@ 2022-07-10 16:43 ` Otavio Salvador
2022-07-18 12:45 ` [OE-core] " Richard Purdie
2022-07-13 16:05 ` [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Sundeep KOKKONDA
2022-07-14 0:08 ` [OE-core] " Alejandro Enedino Hernandez Samaniego
2 siblings, 1 reply; 17+ messages in thread
From: Otavio Salvador @ 2022-07-10 16:43 UTC (permalink / raw)
To: openembedded-core; +Cc: 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-10 16:43 ` [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking Otavio Salvador
@ 2022-07-18 12:45 ` Richard Purdie
2022-07-18 15:49 ` Otavio Salvador
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2022-07-18 12:45 UTC (permalink / raw)
To: Otavio Salvador, openembedded-core
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 12:45 ` [OE-core] " Richard Purdie
@ 2022-07-18 15:49 ` Otavio Salvador
2022-07-18 15:59 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Otavio Salvador @ 2022-07-18 15:49 UTC (permalink / raw)
To: Richard Purdie
Cc: Otavio Salvador, Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 15:49 ` Otavio Salvador
@ 2022-07-18 15:59 ` Richard Purdie
2022-07-18 19:25 ` Otavio Salvador
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2022-07-18 15:59 UTC (permalink / raw)
To: Otavio Salvador
Cc: Otavio Salvador, Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 15:59 ` Richard Purdie
@ 2022-07-18 19:25 ` Otavio Salvador
2022-07-18 21:18 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Otavio Salvador @ 2022-07-18 19:25 UTC (permalink / raw)
To: Richard Purdie, Khem Raj
Cc: Otavio Salvador, Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 19:25 ` Otavio Salvador
@ 2022-07-18 21:18 ` Richard Purdie
2022-07-18 21:41 ` Otavio Salvador
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2022-07-18 21:18 UTC (permalink / raw)
To: Otavio Salvador, Khem Raj
Cc: Otavio Salvador, Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 21:18 ` Richard Purdie
@ 2022-07-18 21:41 ` Otavio Salvador
2022-07-18 22:54 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Otavio Salvador @ 2022-07-18 21:41 UTC (permalink / raw)
To: Richard Purdie
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 21:41 ` Otavio Salvador
@ 2022-07-18 22:54 ` Richard Purdie
2022-07-19 0:07 ` Otavio Salvador
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2022-07-18 22:54 UTC (permalink / raw)
To: Otavio Salvador
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-18 22:54 ` Richard Purdie
@ 2022-07-19 0:07 ` Otavio Salvador
2022-07-20 17:21 ` Richard Purdie
0 siblings, 1 reply; 17+ messages in thread
From: Otavio Salvador @ 2022-07-19 0:07 UTC (permalink / raw)
To: Richard Purdie
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-19 0:07 ` Otavio Salvador
@ 2022-07-20 17:21 ` Richard Purdie
2022-07-20 18:11 ` Otavio Salvador
0 siblings, 1 reply; 17+ messages in thread
From: Richard Purdie @ 2022-07-20 17:21 UTC (permalink / raw)
To: Otavio Salvador
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-20 17:21 ` Richard Purdie
@ 2022-07-20 18:11 ` Otavio Salvador
2022-07-20 18:26 ` Richard Purdie
2022-07-20 19:13 ` Otavio Salvador
0 siblings, 2 replies; 17+ messages in thread
From: Otavio Salvador @ 2022-07-20 18:11 UTC (permalink / raw)
To: Richard Purdie
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-20 18:11 ` Otavio Salvador
@ 2022-07-20 18:26 ` Richard Purdie
2022-07-20 19:13 ` Otavio Salvador
1 sibling, 0 replies; 17+ messages in thread
From: Richard Purdie @ 2022-07-20 18:26 UTC (permalink / raw)
To: Otavio Salvador
Cc: Khem Raj, Otavio Salvador,
Patches and discussions about the oe-core layer
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
2022-07-20 18:11 ` Otavio Salvador
2022-07-20 18:26 ` Richard Purdie
@ 2022-07-20 19:13 ` Otavio Salvador
1 sibling, 0 replies; 17+ messages in thread
From: Otavio Salvador @ 2022-07-20 19:13 UTC (permalink / raw)
To: Otavio Salvador
Cc: Richard Purdie, Khem Raj,
Patches and discussions about the oe-core layer
[-- 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation
2022-07-10 16:42 [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Otavio Salvador
2022-07-10 16:43 ` [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking Otavio Salvador
@ 2022-07-13 16:05 ` Sundeep KOKKONDA
2022-07-14 0:08 ` [OE-core] " Alejandro Enedino Hernandez Samaniego
2 siblings, 0 replies; 17+ messages in thread
From: Sundeep KOKKONDA @ 2022-07-13 16:05 UTC (permalink / raw)
To: openembedded-core
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [OE-core] [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation
2022-07-10 16:42 [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Otavio Salvador
2022-07-10 16:43 ` [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking Otavio Salvador
2022-07-13 16:05 ` [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Sundeep KOKKONDA
@ 2022-07-14 0:08 ` Alejandro Enedino Hernandez Samaniego
2022-07-14 11:24 ` Otavio Salvador
2 siblings, 1 reply; 17+ messages in thread
From: Alejandro Enedino Hernandez Samaniego @ 2022-07-14 0:08 UTC (permalink / raw)
To: Otavio Salvador, openembedded-core
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-07-20 19:13 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-10 16:42 [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Otavio Salvador
2022-07-10 16:43 ` [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking Otavio Salvador
2022-07-18 12:45 ` [OE-core] " Richard Purdie
2022-07-18 15:49 ` Otavio Salvador
2022-07-18 15:59 ` Richard Purdie
2022-07-18 19:25 ` Otavio Salvador
2022-07-18 21:18 ` Richard Purdie
2022-07-18 21:41 ` Otavio Salvador
2022-07-18 22:54 ` Richard Purdie
2022-07-19 0:07 ` Otavio Salvador
2022-07-20 17:21 ` Richard Purdie
2022-07-20 18:11 ` Otavio Salvador
2022-07-20 18:26 ` Richard Purdie
2022-07-20 19:13 ` Otavio Salvador
2022-07-13 16:05 ` [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation Sundeep KOKKONDA
2022-07-14 0:08 ` [OE-core] " Alejandro Enedino Hernandez Samaniego
2022-07-14 11:24 ` Otavio Salvador
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.