public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
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




  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