Open farcaller opened 9 years ago
I just can't find out why we're looking for rustc-serialize
at all. That's new since the successful builds on master. Also noted the libc
dependency being pulled from crates.io that's causing problems; that's new as well.
It's pulled via
[dev-dependencies]
expectest = "*"
Well expectest
depends on num
which depends on rustc-serialize
, which isn't compiled with #![no_std]
.
The std
resolution appears to be the only problem at the moment for the other platforms.
oh wait, dev-dependency
aren't only pulled in for tests?
Hmmm... Well they SHOULD be, but it looks like even in past lives we've been building our dev dependencies in cargo build
and just getting away with it. I don't see a cargo bug about it so it must be something about current implementation that's causing it. That is the underlying problem though. Maybe we're misunderstanding dev-dependencies
? It does seem pretty clear from the cargo docs though that they're supposed to only be pulled in for testing.
Okay, so I had to disable
[dev-dependencies.expectest]
version = "*"
and
[dev-dependencies.volatile_cell]
path = "./volatile_cell"
features = ["replayer"]
at which point it gets stuck only on core:
Compiling rlibc v0.1.3 (https://github.com/mcoffin/rlibc?branch=zinc#8cb879f9)
Running `rustc /root/.cargo/git/checkouts/rlibc-e422ad7ff25b5892/zinc/src/lib.rs --crate-name rlibc --crate-type lib -g -C metadata=3824eae6f8f5db64 -C extra-filename=-3824eae6f8f5db64 --out-dir /hackndev/zinc/target/thumbv6-none-eabi/debug/deps --emit=dep-info,link --target thumbv6-none-eabi -C ar=arm-none-eabi-ar -C linker=arm-none-eabi-gcc -L dependency=/hackndev/zinc/target/thumbv6-none-eabi/debug/deps -L dependency=/hackndev/zinc/target/thumbv6-none-eabi/debug/deps -Awarnings`
/root/.cargo/git/checkouts/rlibc-e422ad7ff25b5892/zinc/src/lib.rs:30:1: 30:19 error: can't find crate for `core`
/root/.cargo/git/checkouts/rlibc-e422ad7ff25b5892/zinc/src/lib.rs:30 extern crate core;
Ahh! Got it. This is a problem with our super-target-fragile implementation of moving the core
dependency in to the tree (instead of having the user compile it and install it in a standard location as would be done if they compiled rust for their specified target). It's really worth it at the end of the day for the end-user not to have to compile libcore manually, but you'll need to add a target-specific dependency on our rust-libcore
to our rlibc
. Here is the Cargo.toml
snippet for the existing targets.
This should be documented on the wiki probably.
[target.thumbv7m-none-eabi.dependencies.core]
git = "https://github.com/hackndev/rust-libcore"
[target.thumbv7em-none-eabi.dependencies.core]
git = "https://github.com/hackndev/rust-libcore"
You'll have to do this:
[target.thumbv7em-none-eabi.dependencies.core]
git = "https://github.com/hackndev/rust-libcore"
+
+[target.thumbv6-none-eabi.dependencies.core]
+git = "https://github.com/hackndev/rust-libcore"
We should also clone mcoffin/rlibc in to hackndev. It was passed over when we cloned bharrisau/rust-libcore in to the hackndev org.
This is now documented on the wiki
Thanks for the tip, now it's only the dev-dependencies thing.
The problem is really on our side somewhere, the simple project works fine: https://gist.github.com/farcaller/15d1c05f12ccf52390f3
Okay, after further experiments I figured it's getting pulled in from volatile cell due to
[dev-dependencies.volatile_cell]
path = "./volatile_cell"
features = ["replayer"]
in main toml. For whatever reason it enables "replayer" feature.
Got the proper test case. I think it's a cargo bug rather than out misconfiguration, filed https://github.com/rust-lang/cargo/issues/1796 to track it.
So this is a cargo issue alright. I'm trying to fix cargo, but a notable side effect for us will break all examples, they pull in dev-dependencies by design. This is a good time to break them in dedicated crates I think.
https://travis-ci.org/hackndev/zinc/builds/70222004
Can someone take a look and maybe have some idea? My only guess is that libcore
build.rs
can't findbuild.sh
due to some paths mixup. No idea why e.g.rustc-serialize
looks for libstd though.