On 07/18/17 15:40, Sebastien Marie wrote:
> On Tue, Jul 18, 2017 at 03:10:26PM +0200, Martijn Rijkeboer wrote:
>> Hi,
>>
>> When I try to run `cargo test` on a Rust project I get the following
>> panic on the Doc-tests (the tests succeed on Linux):
>>
>> Doc-tests kpdb
>> thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err`
>> value: Error { repr: Custom(Custom { kind: Other, error:
>> StringError("no current exe available (short)") }) }', /usr/obj/ports
>> /rust-1.18.0/rustc-1.18.0-src/src/libcore/result.rs:859
>> note: Run with `RUST_BACKTRACE=1` for a backtrace.
>> error: test failed, to rerun pass '--doc'
>>
>> Any suggestions on how to fix this? Some system info below.
>
> The runned program should use env::current_exe() at some point (directly
> or via dependency), and the function is only partially supported under
> OpenBSD.
>
> See https://doc.rust-lang.org/std/env/fn.current_exe.html (and the
> security implication).
>
> The problem is env::current_exe() should return the full pathname of the
> running executable, whereas in your case the program was started using
> execvp() (using $PATH). So the program has no way to know what is its
> own pathname (and there is *no* guarantee that the path is the *running*
> program, and the node wasn't changed).
>
> Note, the problem could be in rustdoc itself. For now, I am working on
> upcoming 1.19.0 release, so probability for a patch for current version
> in ports is low. I will check if an unpatched call of env::current_exe()
> is here or not.
I totally understand your trade-off.
> You could try to set RUSTDOC=/usr/local/bin/rustdoc in your environment,
> before running cargo test. It will use a complete path for calling
> rustdoc, and if the problem is in rustdoc, it should found its own
> pathname.
By setting RUSTDOC the tests succeed so I'm happy. Thanks for your time.
Kind regards,
Martijn Rijkeboer
