Error: environment variable OUT_DIR not defined on ARMv7

[noloader]

I'm trying to build geckodriver from sources. The project depends upon rust and cargo. The platform is a Raspberry Pi 3B+ running Raspbian (fully patched). I'm building on the device, so it is a native build. I despise cross compiles because they are such a pain in the ass. I'm happy to build on-device and trade the extra 10 minutes of build time for peace of mind.

The RPI 3B+ is fully patched, and it is/has:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.8 (stretch)
Release:        9.8
Codename:       stretch

$ gcc --version
gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516

$ gcc -dumpmachine
arm-linux-gnueabihf

$ python2 --version
Python 2.7.13
$ python3 --version
Python 3.5.3

$ rust --version
-bash: rust: command not found
$ cargo --version
cargo 0.15.0 (built 2017-03-22)

$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4
...

cargo build on the RPI 3B+ results in:

$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading hyper v0.12.26
 Downloading mozprofile v0.5.0
 ...
   Compiling adler32 v1.0.3
   Compiling proc-macro2 v0.4.27
   ...
   Compiling crc v1.8.1
   Compiling unicode-width v0.1.5
error: environment variable `OUT_DIR` not defined
 --> /home/jwalton/.cargo/registry/src/github.com-1ecc6299db9ec823/crc-1.8.1/src/crc16.rs:8:18
  |
8 | include!(concat!(env!("OUT_DIR"), "/crc16_constants.rs"));
  |                  ^^^^^^^^^^^^^^^

error: couldn't read "/home/jwalton/.cargo/registry/src/github.com-1ecc6299db9ec823/crc-1.8.1/src/0/crc16_constants.rs": No such file or directory (os error 2)
 --> /home/jwalton/.cargo/registry/src/github.com-1ecc6299db9ec823/crc-1.8.1/src/crc16.rs:8:1
  |
8 | include!(concat!(env!("OUT_DIR"), "/crc16_constants.rs"));
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Build failed, waiting for other jobs to finish...
error: Could not compile `crc`.

To learn more, run the command again with --verbose.
Failed to build geckodriver

This may be relevant:

$ find `pwd` -name crc16_constants.rs
$
$ find /home/jwalton/.cargo/registry/src  -name crc16_constants.rs
$

Unfortunately, I know nothing about rust or cargo. I'm told we have to use it for this task. Also see Geckodriver | Issue 1540.

Here are some related bug reports for the docs and test suite, but I'm not sure what needs to be done when building the tools: Issue 908, Issue 879, and Issue 847.

[ehuss]

cargo 0.15.0 (built 2017-03-22)

I would suspect this version of Cargo is too old.

[noloader]

Thanks @ehuss,

Now open in the Debian issue tracker: Issue 926748, Cargo is too old. It may be fixed in two or three years. (Personally, I've found filing Debian bugs in a waste of time. Nothing seems to get fixed).

Is there anything that can be done in the meantime?

I tried to drop back to v0.17.0 of geckodriver. That versions seems to be roughly the equivalent package for cargo 0.15.0 (if I am parsing dates correctly). It produces errors like:

error[E0277]: the trait bound `*mut core::ops::Fn() + 'static: core::marker::Sync` is not satisfied in `core::fmt::Arguments<'static>`

About all I can seem to do is move the cargo errors around. Does anyone know if cargo works on RPI's?

[sanxiyn]

Debian stretch is stable. It means there will be no new versions of packages. Filing "Cargo is too old" bug to Debian stable release is indeed waste of time, not because Debian doesn't fix bugs (it does), but because that's against Debian policy and hence it will never be fixed.

The next Debian release, buster, is currently in full freeze and will release soon. It will have recent Cargo that works.

[noloader]

Debian stretch is stable. It means there will be no new versions of packages. Filing "Cargo is too old" bug to Debian stable release is indeed waste of time, not because Debian doesn't fix bugs (it does), but because that's against Debian policy and hence it will never be fixed.

Thanks @sanxiyn.

It does not matter to me what Debian does as long as they fix the broken build. Let's wait and see if it gets fixed. I'm not a betting man, but I would happily take this wager from you.

The next Debian release, buster, is currently in full freeze and will release soon. It will have recent Cargo that works.

Yeah, this is pretty much useless. I need a solution now for what is in the field.

[sanxiyn]

I closed your Debian issue, because you are not helping Debian and Debian issue tracker is not an appropriate venue to vent.

[alexcrichton]

I'm going to close this issue as it looks like this is tied back to an older Cargo which is likely fixed in more recent versions of Cargo. I see that some recent comments have been hidden by default, but I'd like to remind all here to remain civil in our discourse and always respect the Rust Code of Conduct. Continued violations of that will result in more moderation actions being taken.

[noloader]

@alexheretic ,

I'm going to close this issue as it looks like this is tied back to an older Cargo which is likely fixed in more recent versions of Cargo.

To state the obvious, it is currently broken in the field. What happens in the future is of no use to users now.

[sanxiyn]

Cargo issue tracker may not be the right place, but I do think this needs to be tracked somewhere, since actual use case is broken.

[anguslees]

To state the obvious, it is currently broken in the field. What happens in the future is of no use to users now.

@noloader: I understand your frustration from debugging a problem only to discover it was due to using an old version of a tool. I think you have some misunderstandings about Debian releases, and hopefully I can help you take better advantage of Debian in your situation:

You appear to be using Debian version "stable" (aka "stretch"). The whole point of "stable" is that it changes rarely (typically 1-3 years), and this is desirable for "stable" environments like servers, deployed embedded devices, etc. The software in "stretch" was frozen in mid-2017, which is why your version of cargo is old, and why you don't see bugs being fixed in the versions you are using.

If you want newer tools, which you most definitely do if you are using this as your Rust development environment, I strongly recommend you upgrade to Debian's "testing" release (aka "buster"). This is a rolling release, meaning it is effectively released continuously (after some light testing in the "unstable" release). If you use "testing" you would have cargo 0.33 (at time of writing), which is substantially newer.

There are plenty of instructions on the internet describing how to do this upgrade. The basic version is replace the string "stable" or "stretch" with "testing" in /etc/apt/sources.list and /etc/apt/sources.list.d/*. Then run apt update and apt full-upgrade.

If ever you are curious about versions of tools in the different Debian releases, you can use the search engine on packages.debian.org. Here is the result for cargo. Note that in your case in particular you are interested in the versions reported for the "armhf" architecture.

I hope you can understand why "too old" bugs against the stable release are going to be closed without action. The package in a previous release is not going to be updated (that's the point of declaring a release snapshot!), and it's a bit like pointing out that the version of some software you have on an old CD on the shelf was not the latest version that was released last week (no kidding! :)
Also, unlike some other distributions, Debian is built by unpaid volunteers. The people packaging up cargo and making it available for your use did so out of nothing but generosity, and they take pride in their work. Accusing volunteers of not responding to bugs and not updating packages, when both those statements are not true, is particularly hurtful.