[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

Hi guys,

I'm trying to build mipsel Rust stuff, and I've had to do this:

8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

After patching, after some long compilation I get:

8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
Building stage0 tool fabricate (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.40s
Install docs stage2 (Some("x86_64-unknown-linux-gnu"))
touch: cannot touch '/usr/local/lib/rust-install-probe': Permission denied
install: error: can't write to destination. consider `sudo`.


command did not execute successfully: "sh"
"/home/alex/git/buildroot/output/build/host-rust-1.33.0/build/tmp/dist/rust-docs-1.33.0-dev-x86_64-unknown-linux-gnu/install.sh"
"--prefix=/usr/local" "--sysconfdir=/etc" "--datadir=/usr/local/share"
"--docdir=/usr/local/share/doc/rust" "--bindir=/usr/local/bin"
"--libdir=/usr/local/lib" "--mandir=/usr/local/share/man"
"--disable-ldconfig"
expected success, got: exit code: 1


failed to run:
/home/alex/git/buildroot/output/build/host-rust-1.33.0/build/bootstrap/debug/bootstrap
install
Build completed unsuccessfully in 0:01:12
make: *** [package/pkg-generic.mk:271:
/home/alex/git/buildroot/output/build/host-rust-1.33.0/.stamp_host_installed]
Error 1
8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<

I'd rather not sudo, as it seems that would bork my rustup-installed Rust?

Cheers,

?lex


On Sat, Jan 18, 2020 at 7:46 PM Alex Corcoles <alex@corcoles.net> wrote:

> Hi guys,
>
> I'm trying to build mipsel Rust stuff, and I've had to do this:
>
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
> From 8c3f68a687b4f94a7c2e20e2020fd1e6f9e2c414 Mon Sep 17 00:00:00 2001
> From: alex <alex@pdp7.net>
> Date: Sat, 18 Jan 2020 19:24:57 +0100
> Subject: [PATCH 1/1] Set RUSTC_TARGET_NAME
>
> Signed-off-by: alex <alex@pdp7.net>
> ---
>  package/rust/rust.mk | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/package/rust/rust.mk b/package/rust/rust.mk
> index 5d14fc6682..258daef331 100644
> --- a/package/rust/rust.mk
> +++ b/package/rust/rust.mk
> @@ -38,6 +38,8 @@ endef
>
>  HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES
>
> +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)
> +
>  define HOST_RUST_CONFIGURE_CMDS
>   ( \
>   echo '[build]'; \
> --
> 2.20.1
>
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
>
> To advance things up (I'm currently compiling LLVM, apparently), as
> otherwise the config.toml created is wrong. I'm attaching the .config I'm
> using (I'm using the non-pre-built host rust- the pre-built one apparently
> doesn't have std).
>
> I certainly doubt what I'm doing is "correct", but maybe you guys want to
> take a look at it.
>
> BTW, tried to cc: Eric as instructed by get-developers, but mail to him
> bounced...
>
> Cheers,
>
> ?lex
> --
>    ___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>
>
> --
>    ___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200118/192cf596/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Yann E. MORIN]

Alex, All,

On 2020-01-18 19:46 +0100, Alex Corcoles spake thusly:
> Hi guys,
> I'm trying to build mipsel Rust stuff, and I've had to do this:
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
> From 8c3f68a687b4f94a7c2e20e2020fd1e6f9e2c414 Mon Sep 17 00:00:00 2001
> From: alex < [1]alex@pdp7.net>
> Date: Sat, 18 Jan 2020 19:24:57 +0100
> Subject: [PATCH 1/1] Set RUSTC_TARGET_NAME
> 
> Signed-off-by: alex < [2]alex@pdp7.net>
> ---
> ?package/rust/ [3]rust.mk | 2 ++
> ?1 file changed, 2 insertions(+)
> 
> diff --git a/package/rust/ [4]rust.mk b/package/rust/ [5]rust.mk
> index 5d14fc6682..258daef331 100644
> --- a/package/rust/ [6]rust.mk
> +++ b/package/rust/ [7]rust.mk
> @@ -38,6 +38,8 @@ endef
> ?
> ?HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES
> ?
> +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)

RUSTC_TARGET_NAME is defined in package/rustc/rustc.mk:

    10 ifeq ($(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS),y)
    11 RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)
    12 endif

So, it is only defined if BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is
set, and this is defined in package/rustc/Config.in.host. It needs a
glibc toolchain (and an x86 or x86_64 host machine).

But your configuration uses uClibc-ng, not glibc, so this is the reason
that it does not work for you.

If you believe the dependency on glibc is too stringent, then this is
the place to fix stuff, not redefine the variable as you suggested.

Regards,
Yann E. MORIN.

> ?define HOST_RUST_CONFIGURE_CMDS
> ? ( \
> ? echo '[build]'; \
> --
> 2.20.1
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
> To advance things up (I'm currently compiling LLVM, apparently), as otherwise the config.toml created is wrong. I'm attaching the
> .config I'm using (I'm using the non-pre-built host rust- the pre-built one apparently doesn't have std).
> I certainly doubt what I'm doing is "correct", but maybe you guys want to take a look at it.
> BTW, tried to cc: Eric as instructed by get-developers, but mail to him bounced...
> Cheers,
> ?lex
> --
> ? ?___
> ?{~._.~}
> ? ( Y )
> ?()~*~()? mail: alex at corcoles dot net
> ?(_)-(_) ? [8]http://alex.corcoles.net/
> 
> --
> ? ?___
> ?{~._.~}
> ? ( Y )
> ?()~*~()? mail: alex at corcoles dot net
> ?(_)-(_) ? [9]http://alex.corcoles.net/
> 
> Links:
> 1. mailto:alex at pdp7.net
> 2. mailto:alex at pdp7.net
> 3. http://rust.mk
> 4. http://rust.mk
> 5. http://rust.mk
> 6. http://rust.mk
> 7. http://rust.mk
> 8. http://alex.corcoles.net/
> 9. http://alex.corcoles.net/


> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

> RUSTC_TARGET_NAME is defined in package/rustc/rustc.mk:
>
>     10 ifeq ($(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS),y)
>     11 RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)
>     12 endif
>
> So, it is only defined if BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is
> set, and this is defined in package/rustc/Config.in.host. It needs a
> glibc toolchain (and an x86 or x86_64 host machine).
>
> But your configuration uses uClibc-ng, not glibc, so this is the reason
> that it does not work for you.
>
> If you believe the dependency on glibc is too stringent, then this is
> the place to fix stuff, not redefine the variable as you suggested.
>

Honestly, I don't have any idea what I'm doing :)

Rust itself supports uclibc on mipsel:

https://forge.rust-lang.org/release/platform-support.html

mipsel-unknown-linux-uclibc is a Tier 3 platform, which is not awesome, but
it could work. Frankly I don't know much about buildroot to hack this up
(or even to know if it's worth trying).

(I'm just trying to run rust-sdl/rust-sdl2 on a RG-300 which uses buildroot
for development purposes. I've managed to build C stuff using SDL
successfully in buildroot, but Rust is proving to be more complex)

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200119/a183a471/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Eric Le Bihan]

Hi!

On 2020-01-18 19:46, Alex Corcoles wrote:
> Hi guys,
>
> I'm trying to build mipsel Rust stuff, and I've had to do this:
[...]
>
>  HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES
>
> +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)
> +
[...]
> To advance things up (I'm currently compiling LLVM, apparently), as
> otherwise the config.toml created is wrong. I'm attaching the .config I'm
> using (I'm using the non-pre-built host rust- the pre-built one apparently
> doesn't have std).
>
> I certainly doubt what I'm doing is "correct", but maybe you guys want to
> take a look at it.

The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is
used to ensure all the conditions to build a rust package are met. One
of them is that the toolchain is glibc-based. This is required, because
the standard library provided by the pre-built host Rust toolchain is
built against glibc.

In your defconfig, the toolchain is uclibc-based and the host Rust
toolchain is built from source.

Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so
is RUSTC_TARGET_NAME.

So there is a bug: the restriction on having a glibc-based toolchain
should apply either when using a pre-built rust toolchain or building
one from source. I'll see how to fix it.

The list of supported platforms [1] mentions GNU glibc and musl, but not
uclibc. Does the build with your defconfig and patch successful?

[1] https://forge.rust-lang.org/release/platform-support.html

Regards,

--
ELB

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

Hi!

The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol
> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is
> used to ensure all the conditions to build a rust package are met. One
> of them is that the toolchain is glibc-based. This is required, because
> the standard library provided by the pre-built host Rust toolchain is
> built against glibc.
>
> In your defconfig, the toolchain is uclibc-based and the host Rust
> toolchain is built from source.
>
> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so
> is RUSTC_TARGET_NAME.
>
> So there is a bug: the restriction on having a glibc-based toolchain
> should apply either when using a pre-built rust toolchain or building
> one from source. I'll see how to fix it.
>
> The list of supported platforms [1] mentions GNU glibc and musl, but not
> uclibc. Does the build with your defconfig and patch successful?
>
> [1] https://forge.rust-lang.org/release/platform-support.html
>

I think I built it successfully after introducing my hack, but as far as I
understand, it is not guaranteed to build in the future (and the opposite
is true, perhaps if it doesn't build today, it will tomorrow). In the link
you sent, mipsel-unknown-linux-uclibc is Tier 3 with std.

If I have some time I will play around with it and see you some results.

IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this
option for non-Tier 1 Rust builds which are not guaranteed to work", or
something like that.

Cheers,

?lex

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200120/bc14caa5/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

I've finally had more time to play with this. It seems that
mipsel-unknown-linux-uclibc works! I've been able to run software built
with it on a real hardware device, although it's very crashy (all
arithmetic operations seem to crash with illegal instruction- probably I
didn't configure my toolchain right or there's a Rust issue...).

I would suggest removing the limitation on uclibc... perhaps with a big
warning flag, though, as I haven't managed to build complex, stable
software.

I've written a bit about the process at:

https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722
https://github.com/alexpdp7/retrofw2-rust

Cheers,

?lex

On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote:

> Hi!
>
> The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol
>> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is
>> used to ensure all the conditions to build a rust package are met. One
>> of them is that the toolchain is glibc-based. This is required, because
>> the standard library provided by the pre-built host Rust toolchain is
>> built against glibc.
>>
>> In your defconfig, the toolchain is uclibc-based and the host Rust
>> toolchain is built from source.
>>
>> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so
>> is RUSTC_TARGET_NAME.
>>
>> So there is a bug: the restriction on having a glibc-based toolchain
>> should apply either when using a pre-built rust toolchain or building
>> one from source. I'll see how to fix it.
>>
>> The list of supported platforms [1] mentions GNU glibc and musl, but not
>> uclibc. Does the build with your defconfig and patch successful?
>>
>> [1] https://forge.rust-lang.org/release/platform-support.html
>>
>
> I think I built it successfully after introducing my hack, but as far as I
> understand, it is not guaranteed to build in the future (and the opposite
> is true, perhaps if it doesn't build today, it will tomorrow). In the link
> you sent, mipsel-unknown-linux-uclibc is Tier 3 with std.
>
> If I have some time I will play around with it and see you some results.
>
> IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this
> option for non-Tier 1 Rust builds which are not guaranteed to work", or
> something like that.
>
> Cheers,
>
> ?lex
>
> --
>    ___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/e8cfc0c9/attachment.html>

[Buildroot] Fwd: "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

I've finally had more time to play with this. It seems that
mipsel-unknown-linux-uclibc works! I've been able to run software built
with it on a real hardware device, although it's very crashy (all
arithmetic operations seem to crash with illegal instruction- probably I
didn't configure my toolchain right or there's a Rust issue...).

I would suggest removing the limitation on uclibc... perhaps with a big
warning flag, though, as I haven't managed to build complex, stable
software.

I've written a bit about the process at:

https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722
https://github.com/alexpdp7/retrofw2-rust

Cheers,

?lex

On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote:

> Hi!
>
> The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol
>> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is
>> used to ensure all the conditions to build a rust package are met. One
>> of them is that the toolchain is glibc-based. This is required, because
>> the standard library provided by the pre-built host Rust toolchain is
>> built against glibc.
>>
>> In your defconfig, the toolchain is uclibc-based and the host Rust
>> toolchain is built from source.
>>
>> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so
>> is RUSTC_TARGET_NAME.
>>
>> So there is a bug: the restriction on having a glibc-based toolchain
>> should apply either when using a pre-built rust toolchain or building
>> one from source. I'll see how to fix it.
>>
>> The list of supported platforms [1] mentions GNU glibc and musl, but not
>> uclibc. Does the build with your defconfig and patch successful?
>>
>> [1] https://forge.rust-lang.org/release/platform-support.html
>>
>
> I think I built it successfully after introducing my hack, but as far as I
> understand, it is not guaranteed to build in the future (and the opposite
> is true, perhaps if it doesn't build today, it will tomorrow). In the link
> you sent, mipsel-unknown-linux-uclibc is Tier 3 with std.
>
> If I have some time I will play around with it and see you some results.
>
> IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this
> option for non-Tier 1 Rust builds which are not guaranteed to work", or
> something like that.
>
> Cheers,
>
> ?lex
>
> --
>    ___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/



-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/2b401c07/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

Some further investigation reveals that Rust made the mips* targets
mips32r2 by default, while the system I'm trying to compile to is only
mips32 (no r2). This seems to be the source of my issues:

https://github.com/rust-lang/rust/pull/48874

So if buildroot wants Rust to work on JZ4760B and similar popular CPUs, I
think it should define a new Rust target for mips32 without r2 instruction
set.

That goes a bit beyond my knowledge (esp. buildroot), so if someone wants
to help, I'd be happy to do whatever I can.

On Mon, Feb 3, 2020 at 6:08 PM Alex Corcoles <alex@corcoles.net> wrote:

> I've finally had more time to play with this. It seems that
> mipsel-unknown-linux-uclibc works! I've been able to run software built
> with it on a real hardware device, although it's very crashy (all
> arithmetic operations seem to crash with illegal instruction- probably I
> didn't configure my toolchain right or there's a Rust issue...).
>
> I would suggest removing the limitation on uclibc... perhaps with a big
> warning flag, though, as I haven't managed to build complex, stable
> software.
>
> I've written a bit about the process at:
>
>
> https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722
> https://github.com/alexpdp7/retrofw2-rust
>
> Cheers,
>
> ?lex
>
> On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote:
>
>> Hi!
>>
>> The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol
>>> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is
>>> used to ensure all the conditions to build a rust package are met. One
>>> of them is that the toolchain is glibc-based. This is required, because
>>> the standard library provided by the pre-built host Rust toolchain is
>>> built against glibc.
>>>
>>> In your defconfig, the toolchain is uclibc-based and the host Rust
>>> toolchain is built from source.
>>>
>>> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so
>>> is RUSTC_TARGET_NAME.
>>>
>>> So there is a bug: the restriction on having a glibc-based toolchain
>>> should apply either when using a pre-built rust toolchain or building
>>> one from source. I'll see how to fix it.
>>>
>>> The list of supported platforms [1] mentions GNU glibc and musl, but not
>>> uclibc. Does the build with your defconfig and patch successful?
>>>
>>> [1] https://forge.rust-lang.org/release/platform-support.html
>>>
>>
>> I think I built it successfully after introducing my hack, but as far as
>> I understand, it is not guaranteed to build in the future (and the opposite
>> is true, perhaps if it doesn't build today, it will tomorrow). In the link
>> you sent, mipsel-unknown-linux-uclibc is Tier 3 with std.
>>
>> If I have some time I will play around with it and see you some results.
>>
>> IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this
>> option for non-Tier 1 Rust builds which are not guaranteed to work", or
>> something like that.
>>
>> Cheers,
>>
>> ?lex
>>
>> --
>>    ___
>>  {~._.~}
>>   ( Y )
>>  ()~*~()  mail: alex at corcoles dot net
>>  (_)-(_)  http://alex.corcoles.net/
>>
>>
>
> --
>    ___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200205/2c32b651/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

Hi guys,

Just managed to get everything working. I've documented the whole process
at:

https://github.com/alexpdp7/retrofw2-rust

The problems are:

1) Rust updated their mips targets to mips32r2, while the kind of devices
I'm using are plain non-r1 mips32. I created a patch for buildroot that
patches Rust (on top of a patch I found that bumps it to Rust 1.40.0) to
use the proper instruction set. I've opened a bug to see if they change the
target or add a new one at:

https://github.com/rust-lang/rust/issues/68865

2) buildroot doesn't support building Rust for uclibc, I hardcoded that. It
would be nice to write a proper solution to this, but I'm not familiar
enough with buildroot. Does anyone know where I could request that?

3) I had some issues with sdl-mixer, which I fixed by pulling RetroFW's
sdl-mixer. This is even more terrible, but I have even less idea about how
to fix it.

Cheers,

?lex

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200206/1299ec05/attachment.html>

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Vincent Fazio]

Alex,

On 2/6/20 11:18 AM, Alex Corcoles wrote:
> Hi guys,
>
> Just managed to get everything working. I've documented the whole 
> process at:
>
> https://github.com/alexpdp7/retrofw2-rust
>
> The problems are:
>
> 1) Rust updated their mips targets to mips32r2, while the kind of 
> devices I'm using are plain non-r1 mips32. I created a patch for 
> buildroot that patches Rust (on top of a patch I found that bumps it 
> to Rust 1.40.0) to use the proper instruction set. I've opened a bug 
> to see if they change the target or add a new one at:
>
> https://github.com/rust-lang/rust/issues/68865
>
I'm not familiar with Rust, but there should be a cleaner way to set the 
target cpu than hacking the default. Preferably the target MIPS cpu 
selected within Buildroot would inform the target cpu?

A quick search seems to suggest this may be possible 
(https://gitissue.com/issues/5a1e9e776805170abd3c8a38):

[build]
target = "mipsel-unknown-linux-gnu"

[target.mipsel-unknown-linux-gnu]
rustflags = [
 ? "-C", "link-arg=-EL",
 ? "-C", "target-cpu=mips32",
 ? "-C", "target-feature=+mips32,-mips32r2,-fpxx,-nooddspreg",
]


> 2) buildroot doesn't support building Rust for uclibc, I hardcoded 
> that. It would be nice to write a proper solution to this, but I'm not 
> familiar enough with buildroot. Does anyone know where I could request 
> that?
>
> 3) I had some issues with sdl-mixer, which I fixed by pulling 
> RetroFW's sdl-mixer. This is even more terrible, but I have even less 
> idea about how to fix it.
>
> Cheers,
>
> ?lex
>
> -- 
> ?___
> ?{~._.~}
> ? ( Y )
> ?()~*~() mail: alex at corcoles dot net
> ?(_)-(_) http://alex.corcoles.net/
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
Vincent Fazio
Embedded Software Engineer - Linux
Extreme Engineering Solutions, Inc
http://www.xes-inc.com

[Buildroot] "PATCH": hack to be able to build Rust targetting MIPS

[Alex Corcoles]

Hi Vincent,

On Thu, Feb 6, 2020 at 6:50 PM Vincent Fazio <vfazio@xes-inc.com> wrote:

> I'm not familiar with Rust, but there should be a cleaner way to set the
> target cpu than hacking the default. Preferably the target MIPS cpu
> selected within Buildroot would inform the target cpu?
>
> A quick search seems to suggest this may be possible
> (https://gitissue.com/issues/5a1e9e776805170abd3c8a38):
>
> [build]
> target = "mipsel-unknown-linux-gnu"
>
> [target.mipsel-unknown-linux-gnu]
> rustflags = [
>    "-C", "link-arg=-EL",
>    "-C", "target-cpu=mips32",
>    "-C", "target-feature=+mips32,-mips32r2,-fpxx,-nooddspreg",
> ]
>

Yeah, probably there are slightly cleaner solutions. I think that Rust
targetting mips32r2 by default sucks a little bit, so I'm not losing hope
completely that the change will be reverted. If they do so, I think it
would be quite easy for buildroot to iron out the few niggles required to
get this to work.

However, I'm not really knowledgeable about buildroot, so all the patches
involved in this are terrible. I saw the solution you quote at:

https://github.com/rust-lang/rust/issues/37507#issuecomment-476026815

, but I wasn't sure how to plug that cleanly into buildroot, so I went for
the ugly solution. Perhaps I can plug that into buildroot/package/rust/
rust.mk, though. If I have some time I will try to clean things up
(unfortunately, I was unemployed since mid-November, which gave me tons of
spare time for this silly stuff... but I start a new job on Monday, so I
won't have so much time..,).

If someone wants to spend time on this, I will be happy to test or
whatever, though.

Cheers,

?lex
-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200206/9e12a4ac/attachment.html>