Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
5o50 opened this issue Mar 10, 2020 · 35 comments
Open

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

5o50 opened this issue Mar 10, 2020 · 35 comments
Labels

Comments

@5o50
Copy link

5o50 commented Mar 10, 2020

Version(s) of meta-rust

Master (d0dc19a)

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
Copy link
Author

5o50 commented Mar 12, 2020

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
Copy link

remleduff commented Apr 20, 2020

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.

@codyps codyps added the bug label Sep 2, 2020
@jwinarske
Copy link

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
Copy link

cmcqueen commented Nov 1, 2021

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 448047c.

@jwinarske
Copy link

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

@cmcqueen
Copy link

cmcqueen commented Nov 5, 2021

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
Copy link

jwinarske commented Nov 5, 2021

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
Copy link

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
Copy link

cmcqueen commented Nov 7, 2021

@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
Copy link

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

@cmcqueen
Copy link

cmcqueen commented Nov 8, 2021

$ 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
Copy link

@cmcqueen Is this a public project you can share?

@cmcqueen
Copy link

cmcqueen commented Nov 8, 2021

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
Copy link

cmcqueen commented Nov 8, 2021

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
Copy link

cmcqueen commented Nov 8, 2021

@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
Copy link

jwinarske commented Nov 10, 2021

@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
Copy link

cmcqueen commented Nov 10, 2021

@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
Copy link

jwinarske commented Nov 10, 2021

@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
Copy link

$ 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
Copy link

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
Copy link

cmcqueen commented Jan 17, 2022

@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
Copy link

@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
Copy link

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

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

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

@otavio
Copy link
Contributor

otavio commented Jun 28, 2022

Have this been fixed?

@jwinarske
Copy link

@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
Copy link

pabigot commented Nov 20, 2022

@otavio Still present in poky at current master 44bb88cc869f3b42440d6f7aad000e706b739a2b building for raspberrypi4-64; overriding libstd-rs as described in #266 (comment) still fixes it.

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

@jwinarske
Copy link

akiernan added a commit to zuma-array/meta-rust that referenced this issue Dec 21, 2022
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
kraj pushed a commit to YoeDistro/poky that referenced this issue Dec 21, 2022
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust/meta-rust#266)

(From OE-Core rev: 62527d5dadb79c70731e1dfd7b1f71495c78b267)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rpurdie pushed a commit to yoctoproject/poky that referenced this issue Dec 23, 2022
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust/meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
halstead pushed a commit to openembedded/openembedded-core that referenced this issue Dec 26, 2022
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust/meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
akiernan added a commit to zuma-array/meta-rust that referenced this issue Dec 30, 2022
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
foxsen pushed a commit to foxsen/poky that referenced this issue Jan 2, 2023
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust/meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
asmuth added a commit to nyantec/meta-rust that referenced this issue Apr 18, 2023
@jaskij
Copy link

jaskij commented Aug 29, 2023

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

@qarmin
Copy link

qarmin commented Sep 20, 2023

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
Copy link

Is there any fix for this issue on 1.72?

jwinarske added a commit to meta-flutter/meta-flutter that referenced this issue Jan 4, 2024
-removes workaround for `can't find crate for proc_macro` when compiling proc-macro2`
-meta-rust/meta-rust#266
-#370

Signed-off-by: Joel Winarske <joel.winarske@gmail.com>
@jaskij
Copy link

jaskij commented Apr 10, 2024

To everyone still stuck with this, or those who come here from a search result, an answer has been posted in #425 (comment)

@jwinarske
Copy link

@jaskij What versions have you tested that with? Also not sure if this repo is used verbatim in Yocto.

@jwinarske
Copy link

That said I only use this repo for dunfell

@jaskij
Copy link

jaskij commented Apr 10, 2024

@jwinarske 1.75, kirkstone, but I'm doing x86-64 -> x86-64 so there may be some host contamination that slipped by. So far the only thing I have confirmed is a successful build.

daregit pushed a commit to daregit/yocto-combined that referenced this issue May 22, 2024
Building libstd-rs from library/std omits proc_macro from the sysroot.
Using library/test causes that to be installed which then allows cargo
to build (meta-rust/meta-rust#266)

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
@dougcooper
Copy link

the recommended fix in this thread is broken in 1.78.0 causing the error:

error: Package "test v0.0.0 (path to src)" does not have the feature "backtrace"

the fix can be adjusted with modification per this issue:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests