Cargo cross-build is broken

[farcaller]

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 find build.sh due to some paths mixup. No idea why e.g. rustc-serialize looks for libstd though.

[mcoffin]

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.

[farcaller]

It's pulled via

[dev-dependencies]
expectest = "*"

[mcoffin]

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.

[farcaller]

oh wait, dev-dependency aren't only pulled in for tests?

[mcoffin]

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.

[farcaller]

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;

[mcoffin]

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.

[mcoffin]

This is now documented on the wiki

[farcaller]

Thanks for the tip, now it's only the dev-dependencies thing.

https://travis-ci.org/hackndev/zinc/jobs/70249051

[farcaller]

The problem is really on our side somewhere, the simple project works fine: https://gist.github.com/farcaller/15d1c05f12ccf52390f3

[farcaller]

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.

[farcaller]

Got the proper test case. I think it's a cargo bug rather than out misconfiguration, filed rust-lang/cargo#1796 to track it.

[farcaller]

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.