Moving a compiled binary to a clean OS would throw `cannot install provided ErrorHook`

[xphoniex]

I'm compiling binaries from this project, and it's working fine on the dev machine. However, when I move the binaries to a clean linux os, running the bins returns this error:

$ cast
Error: cannot install provided ErrorHook, a hook has already been installed

Location:
cli/src/handler.rs:70:13

and the line in question is:

eyre::set_hook(Box::new(move |_| Box::new(Handler)))?;

There's also a related issue where people have ran into the same problem on Win 10.

What is causing this?

[xphoniex]

Polite reminder @yaahc

[yaahc]

Thank you, I'm sorry for the long delay, I'll make sure to resolve this asap (probably after the new year).

[davidcornu]

I've been watching this thread as I recently ran into the same error message after introducing a seemingly unrelated change on a project and finally figured out what was going on. I'm documenting it here in case it can be useful to others.

When the auto-install feature is enabled (which it is by default), if an error handler is needed but one isn't configured yet, eyre will install a default one: https://github.com/yaahc/eyre/blob/c32a8d0b6799ef4c862df1034202f9d6e5a5f400/src/lib.rs#L600-L603

What happened in my case was that I introduced some code that triggered and logged an eyre::Report before the code that setup the error handler, which meant that by the time it was executed the default handler was already in place. This led to a lot of confusion on my part as I wasn't aware of the default handler behaviour and assumed I was somehow trying to set up a handler twice.

This is quite similar to your description @xphoniex, as in my case the new code I introduced was actually checking for the presence of a file that exists on some systems but not others.

Hope this helps.

[mpeyfuss]

I was able to solve this exact issue by ensuring that git and libusb are installed on the new machine where the compiled binaries are moved to. Hopefully this helps for your issue.

[xphoniex]

Sorry, a bit confusing, is this a typo, or does commit https://github.com/eyre-rs/eyre/pull/110/commits/615d16ca0dd6a1c2e34e668607b83bc3f5c49c32 actually resolve this issue @dbanty ?

Edit: I think that commit refers to this issue, might wanna re-open this @ten3roberts

[dbanty]

Hmm, looks like pulling color-eyre into the workspace also pulled in the commit history, which means commits that referenced closing issues for color-eyre now retroactively closed issues for eyre 😱. What a fun problem 😅

[ten3roberts]

Thank you for putting this to my attention.

Not only is it closing issues, but closing unrelated issues just because they have the same issue number, grr.

I'll go through any other closed issues and see if there are any more to reopen (and fix :stuck_out_tongue_closed_eyes: )

[ten3roberts]

As stated in the issue, it is the auto install being a footgun, which imho is an anti feature.

Tracing does not do anything by default as this easily leads to unexpected behavior.

We've run into a similar issue with the compile probes, and want to give all this a stir up and remove the probes and instead opting for cargo cfg flags to enable nightly behavior as they are prone to silently breaking or misleading behavior.