From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Khem Raj <raj.khem@gmail.com>,
Otavio Salvador <otavio@ossystems.com.br>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Date: Wed, 20 Jul 2022 19:26:41 +0100 [thread overview]
Message-ID: <25c967efe6c74aa9c0a3bcc71a90f59bfd1ac59a.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAP9ODKpcXKzG_kw4OgdPnZx51eBDKqq45XuCQFXKfD839qpruw@mail.gmail.com>
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
next prev parent reply other threads:[~2022-07-20 18:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25c967efe6c74aa9c0a3bcc71a90f59bfd1ac59a.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--cc=otavio@ossystems.com.br \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox