aarch64: can't find crate for `proc_macro`` when compiling proc-macro2

[5o50]

Version(s) of meta-rust

Master (d0dc19aa78883c6927b8287267ba283760417fe7)

Version(s) of poky and/or oe-core

poky: (Sep 8 2019) 6d2e12e79211b31cdf5ea824fb9a8be54ba9a9eb

Expected result

Using cargo only im able to successfully cross-compile and run my code on the target aarch64-unknown-linux-gnu.

Using Yocto and meta-rust the build fails with error[E0463]: can't find crate for proc_macro`` when compiling proc-macro2.

any idea ?

thank you

Actual result

Build Configuration:
BB_VERSION           = "1.42.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-fslc-linux"
MACHINE              = "imx8mmevk"
DISTRO               = "fslc-wayland"
DISTRO_VERSION       = "2.7"
TUNE_FEATURES        = "aarch64 cortexa53 crc crypto"
TARGET_FPU           = ""
meta                 
meta-poky            = "HEAD:6d2e12e79211b31cdf5ea824fb9a8be54ba9a9eb"
meta-oe              
meta-multimedia      
meta-python          = "HEAD:3bdbf72e3a4bf18a4a2c7afbde4f7ab773aeded9"
meta-freescale       = "HEAD:2142f7ded1b3115ccc21f7575fd83e2376247193"
meta-freescale-3rdparty = "HEAD:da422478d38e744283bcf61123c4a526396c7030"
meta-freescale-distro = "HEAD:d4e77ea682fa10d0d54a723b3d3099c44fc5e95c"
meta-networking      
meta-filesystems     = "HEAD:3bdbf72e3a4bf18a4a2c7afbde4f7ab773aeded9"
meta-rust            = "master:d0dc19aa78883c6927b8287267ba283760417fe7"
meta-browser         = "HEAD:5f365ef0f842ba4651efe88787cf9c63bc8b6cb3"
meta-noos            = "<unknown>:<unknown>"
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| error[E0463]: can't find crate for `proc_macro`
|   --> /usr/src/debug/pocket/0.1.0.AUTOINC+e82af10ec8-r0/cargo_home/bitbake/proc-macro2-1.0.6/src/lib.rs:86:1
|    |
| 86 | extern crate proc_macro;
|    | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
| 
| '+v8' is not a recognized feature for this target (ignoring feature)
| error: aborting due to previous error
| 
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| For more information about this error, try `rustc --explain E0463`.
| '+v8' is not a recognized feature for this target (ignoring feature)
| '+v8' is not a recognized feature for this target (ignoring feature)
| error: could not compile `proc-macro2`.
| 
| Caused by:
|   process didn't exit successfully: `rustc --edition=2018 --crate-name proc_macro2 /home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/cargo_home/bitbake/proc-macro2-1.0.6/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=871b2ad645127a9c -C extra-filename=-871b2ad645127a9c --out-dir /home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/git/target/aarch64-fslc-linux/release/deps --target aarch64-fslc-linux -C linker=/home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/wrapper/target-rust-ccld -L dependency=/home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/git/target/aarch64-fslc-linux/release/deps -L dependency=/home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/git/target/release/deps --extern unicode_xid=/home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/git/target/aarch64-fslc-linux/release/deps/libunicode_xid-5c908667fe25b206.rmeta --cap-lints allow -L /home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0/recipe-sysroot/usr/lib/rust --remap-path-prefix=/home/jimmy/Desktop/neo-noos-warrior/build-imx8mmevk-wayland/tmp/work/aarch64-fslc-linux/pocket/0.1.0.AUTOINC+e82af10ec8-r0=/usr/src/debug/pocket/0.1.0.AUTOINC+e82af10ec8-r0 --cfg use_proc_macro --cfg wrap_proc_macro` (exit code: 1)
| warning: build failed, waiting for other jobs to finish...

Steps to reproduce

bitbake core-image-full

[5o50]

after some testing it's clear that the generated path [...]/recipe-sysroot/usr/lib/rust is missing a file likelibproc_macro[...].rlib

I'm able to find it on my host standalone cargo toolchain install for the same target. and my build for the same target is successful.

I dont know why meta-rust when setting up the toolchain is not generating this file. any idea ?

[remleduff]

I've been looking at this layer lately, and ran across a similar problem. The quickest, but maybe not most correct fix is to change meta-rust/recipes-devtools/rust/libstd-rs.inc:

from: S = "${RUSTSRC}/src/libstd"

to: S = "${RUSTSRC}/src/libtest"

Building libtest will actually build both libtest and libstd, and also includes libproc_macro.

[jwinarske]

I'm hitting this with a few commits back on master 1.51.0. Changing libstd-rs to libtest has no affect; even after

bitbake libstd-rs -c do_cleansstate -f
bitbake libstd-rs

libstd-rs is only building native version of proc_macro

dev@1ab55b927c25:~/tmp-glibc/work/aarch64-oe-linux/libstd-rs$ find -iname libproc*.rlib
./1.51.0-r0/recipe-sysroot-native/usr/lib/rustlib/x86_64-linux/lib/libproc_macro-d72bc99014fc97e5.rlib

Can anyone suggest another workaround?

[cmcqueen]

I'm encountering this issue while building a Rust project for aarch64. The project is based on the Rocket web server, v0.5-rc. I had no problems until I added the crate rocket_auth (v0.4.0), and now I'm getting this error trying to build the project in Yocto.

I'm currently using meta-rust 448047c7e4746eac8f0a96a2e3966b2219e2a4ca.

[jwinarske]

Now that rust support is in OE core I need to test with updated branch. I suspect the issue is still there.

[cmcqueen]

I'm comparing my Yocto poky/build/tmp/work/aarch64-poky-linux/libstd-rs/1.54.0-r0/packages-split/libstd-rs-dev/usr/lib/rust to my ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib, seeing what *.rlib are there.

The local rustup dir has these that are not in the Yocto poky dir:

• libgetopts
• libproc_macro
• libprofiler_builtins
• librustc_std_workspace_std
• libterm
• libtest
• libunwind

Why are these ones in the rustup dir but not in the Yocto poky dir?

[jwinarske]

I suspect the build breaks at the missing libproc_macro, and never gets to the others. If you look at the source proc_macro has it's own directory, and is the exception. In my case what's odd is that it's attempting to link a cross compiled libproc_macro. Libproc_macro should only ever be host.

[jwinarske]

Did you try setting LD_LIBRARY RUNTIME to path in sysroot-native that has proc_macro? Given proc_macros are only built/run on host, LD_LIBRARY_RUNTIME can be used to augment paths from sysroot-native.

[cmcqueen]

@jwinarske wrote:

In my case what's odd is that it's attempting to link a cross compiled libproc_macro. Libproc_macro should only ever be host.

and also

Given proc_macros are only built/run on host, LD_LIBRARY_RUNTIME can be used to augment paths from sysroot-native.

I don't think this is correct. For non-Yocto builds, I installed the aarch64 cross-compile toolchain using rustup. In the provided lib directory ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib, I see libproc_macro-3f1222cb41e97635.rlib. That implies that the library is also needed for the cross-compile target.

I tested this:

1. Have a project that has a dependency on proc_macro. (in my case, I'm working on web frameworks, using either rocket 0.5-rc1 with rocket_auth, or alternatively using warp with askama)
2. cargo clean --target=aarch64-unknown-linux-gnu
3. In ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib, delete or rename libproc_macro-3f1222cb41e97635.rlib.
4. cargo build --target=aarch64-unknown-linux-gnu
5. The result is, I get a build error error[E0463]: can't find crate for `proc_macro` , when it tries to build proc-macro2-1.0.32.

So, I think your hypothesis is incorrect, and the Yocto libstd-rs recipe needs to build libproc_macro.rlib for the target as well.

[jwinarske]

@cmcqueen What's the machine architecture of libproc_macro-3f1222cb41e97635.rlib? readelf -h libproc_macro-3f1222cb41e97635.rlib

[cmcqueen]

$ readelf -h libproc_macro-3f1222cb41e97635.rlib

File: libproc_macro-3f1222cb41e97635.rlib(proc_macro-3f1222cb41e97635.proc_macro.3f08mrfg-cgu.0.rcgu.o)
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          4736032 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         975
  Section header string table index: 1

File: libproc_macro-3f1222cb41e97635.rlib(lib.rmeta)
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          1848184 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         5
  Section header string table index: 4

[jwinarske]

@cmcqueen Is this a public project you can share?

[cmcqueen]

Is this a public project you can share?

No, it's private for my employer. But, I'll see if I can make a "Minimal Reproducible Example" (MRE).

[cmcqueen]

Here's a minimal example:

1. cargo new warp-hello
2. In Cargo.toml, add:

   [dependencies]
   askama = "0.10.5"
   tokio = { version = "1.13.0", features = ["full"] }
   warp = { version = "0.3.1", features = ["tls"] }
   

3. Copy the warp hello example code from warp/examples/hello.rs into main.rs
4. cargo build --target=aarch64-unknown-linux-gnu

I think it's the askama dependency in particular that pulls in proc_macro2 which in turn needs proc_macro.

[cmcqueen]

@jwinarske wrote:

Changing libstd-rs to libtest has no affect

S gets overwritten in libstd-rs_1.54.0.bb etc since rust 1.47+. So try changing it in libstd-rs_1.54.0.bb rather than libstd-rs.inc:

-S = "${RUSTSRC}/library/std"
+S = "${RUSTSRC}/library/test"

That can be done in a libstd-rs_1.54.0.bbappend.

[jwinarske]

@cmcqueen You example builds fine on desktop for host (x86_64), but fails cross compiling on Desktop for aarch64. I would suggest that needs to be addressed prior to attempting to build for Yocto...

error: failed to run custom build command for `ring v0.16.20`

When I reported changing S not having an impact was with 1.45, and in my case the problem was addressing runtime dependency problems (CXX binding nonsense).

[cmcqueen]

@jwinarske I didn't encounter error: failed to run custom build command for `ring v0.16.20` . I'm using Rust 1.54.0-x86_64-unknown-linux-gnu on Ubuntu 20.04.3 (64-bit). What are you using?

[jwinarske]

@cmcqueen

$ cargo --version && rustc --version
cargo 1.54.0 (5ae8d74b3 2021-06-22)
rustc 1.54.0 (a178d0322 2021-07-26)
$ uname -a
Linux joel-ThinkPad-T495 5.11.0-38-generic #42~20.04.1-Ubuntu SMP Tue Sep 28 20:41:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[cmcqueen]

$ cargo --version && rustc --version
cargo 1.54.0 (5ae8d74b3 2021-06-22)
rustc 1.54.0 (a178d0322 2021-07-26)
$ uname -a
Linux ir-craig-vm1 5.11.0-40-generic #44~20.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Sorry, I'm at a loss to explain the ring v0.16.20 build error.

[cmcqueen]

To cross-compile ring and complete the cross-compile of the whole example, you need to install the cross-compile tools such as aarch64-linux-gnu-gcc. On Ubuntu, you can do:

sudo apt install gcc-aarch64-linux-gnu

You also need to create a file ~/.cargo/config that contains:

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

[cmcqueen]

@jwinarske have you been able to investigate this further? With my previous comment, you should be able to manually cross-compile for the aarch64 target, I think.

[jwinarske]

@cmcqueen not yet. I've been working around it via Yocto SDK and Rust cross Canadian toolchain. I will be looking at this in ~three weeks.

[jwinarske]

@cmcqueen I took a look at this today. Using bbappend fixes the issue.

recipes-devtools/rust/libstd-rs_%.bbappend

S = "${RUSTSRC}/library/test"

[otavio]

Have this been fixed?

[jwinarske]

@otavio The only way to work around this is to add listed-rs_%.bbappend as I indicate above. This should get an official fix, as this is a work around.

[pabigot]

@otavio Still present in poky at current master 44bb88cc869f3b42440d6f7aad000e706b739a2b building for raspberrypi4-64; overriding libstd-rs as described in https://github.com/meta-rust/meta-rust/issues/266#issuecomment-1125477963 still fixes it.

https://github.com/rust-lang/rustc-dev-guide/pull/1389 seems to identify the root cause of the problem, and changing S in OE-Core may well be the right solution.

[jwinarske]

@otavio This is my solution for now: https://github.com/meta-flutter/meta-flutter/blob/kirkstone/recipes-devtools/rust/libstd-rs_%25.bbappend

[jaskij]

Is it just me, or does 1.71+ break the accepted workaround for this issue?

[qarmin]

Same problem with 1.72.

Changing library/std into library/test in meta-rust/recipes-devtools/rust/libstd-rs_1.72.0.bb not helps

ERROR: libstd-rs-1.72.0-r0 do_compile: ExecutionError('/home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/temp/run.do_compile.2683002', 101, None, None)
ERROR: Logfile of failure stored in: /home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/temp/log.do_compile.2683002
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: cargo = /home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/recipe-sysroot-native/usr/bin/cargo
| NOTE: rustc =
| NOTE: cargo build -v --target arm-oe-linux-gnueabi --release --manifest-path=/home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/rustc-1.72.0-src/library/test//Cargo.toml --features 'panic-unwind backtrace'
| error: Package `test v0.0.0 (/home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/rustc-1.72.0-src/library/test)` does not have the feature `backtrace`
| WARNING: exit code 101 from a shell command.
| ERROR: ExecutionError('/home/koot/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/libstd-rs/1.72.0-r0/temp/run.do_compile.2683002', 101, None, None)
ERROR: Task (/home/koot/meta-rust/recipes-devtools/rust/libstd-rs_1.72.0.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2564 tasks of which 2563 didn't need to be rerun and 1 failed.

removing panic-unwind and backtrace features shows different errors

[abdelalkuor]

Is there any fix for this issue on 1.72?