interprocess
interprocess copied to clipboard
does not compile on FreeBSD
Describe the bug Fails to compile on FreeBSD 13 amd64:
Compiling interprocess v1.1.1 (XXXXX/interprocess.git)
error[E0432]: unresolved imports `libc::SIGPOLL`, `libc::SO_PASSCRED`, `libc::SO_PEERCRED`, `libc::SCM_CREDENTIALS`, `libc::ucred`
--> src/os/unix/imports.rs:51:13
|
51 | SIGPOLL,
| ^^^^^^^ no `SIGPOLL` in the root
52 | SO_PASSCRED,
| ^^^^^^^^^^^ no `SO_PASSCRED` in the root
53 | SO_PEERCRED,
| ^^^^^^^^^^^ no `SO_PEERCRED` in the root
54 | SCM_CREDENTIALS,
| ^^^^^^^^^^^^^^^ no `SCM_CREDENTIALS` in the root
55 | socklen_t, 56 | ucred,
| ^^^^^ no `ucred` in the root
|
help: a similar name exists in the module |
51 | SIGILL,
| ^^^^^^ help: a similar name exists in the module
|
56 | xucred,
| ^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `interprocess`
To Reproduce
cargo build
Expected behavior successful compilation
Additional context
Replacing all instances of target_os = "macos", target_os = "ios"
with target_os = "macos", target_os = "ios", target_os = "freebsd"
resolves the issue, but I'm not sure if that's the best solution
Issue is no longer seen in latest master. Looking forward to 1.1.2 release and updates to downstream dependents (zellij).
This is still a problem. Is 1.1.2 going to be released?
The release that's in development is actually 1.2.0, I'm skipping 1.1.2, but I'm not making much progress right now because of personal circumstances. I feel like it would be more difficult to backtrack the changes on the main
branch to only the ones that fix FreeBSD support and release that as a version than to just release 1.2.0 at last.
Anyway, @bdrewery, if you need to run your software on FreeBSD as soon as possible, you can pull it in as a pre-release like this:
[dependencies]
interprocess = "1.2.0"
[patch.crates-io]
interprocess = { git = "https://github.com/kotauskas/interprocess", rev = "fc5f2a2" }
This will override the interprocess
dependency with the specified commit, which Cargo will pull directly from this repo. There's no risk of accidental breakage as I make changes on main
, since the commit hash is locked and can only be upgraded manually if you edit your manifest accordingly. Crates.io allows this kind of dependency, because it's technically not a Git dependency, but instead a Crates.io dependency with an override. When 1.2.0 releases, you'll be able to remove [patch.crates-io]
to get the crate in the usual way from Crates.io instead.
I'll leave the issue open just so I can keep track of things that are going to be fixed by the release of 1.2.0.
Additional context Replacing all instances of
target_os = "macos", target_os = "ios"
withtarget_os = "macos", target_os = "ios", target_os = "freebsd"
resolves the issue, but I'm not sure if that's the best solution
Hi,
Same problem with editors/lapce 0.2.0 at PR 266232 that depends on interprocess-1.1.1 crate and I patch it manually so it builds ok.
I've tried to force latest commit to see if it gets patched to latest commit in cargo-crates list:
interprocess-1.1.1 \
interprocess@git+https://github.com/kotauskas/interprocess\#42ef72ef1f4f912c65da1c86a36fb619e34c0a13
without success, maybe I missing something.
Cheers
This is still a problem. Is 1.1.2 going to be released?
Hi,
Did you get success with:
[dependencies]
interprocess = "1.2.0"
[patch.crates-io]
interprocess = { git = "https://github.com/kotauskas/interprocess", rev = "fc5f2a2" }
?
If you have a port using it please tell me so I can take a look and implement it at PR 266232
Cheers
[dependencies] interprocess = "1.2.0" [patch.crates-io] interprocess = { git = "https://github.com/kotauskas/interprocess", rev = "fc5f2a2" }
I'm using this example at lapce 0.2.0:
/lapce-proxy/Cargo.toml
/lapce-data/Cargo.toml
[dependencies]
interprocess = "1.2.0"
[patch.crates-io]
interprocess = { git = "https://github.com/kotauskas/interprocess", rev = "42ef72e" }
But it fails with cargo generate-lockfile
:
(...)
Updating git repository `https://github.com/maxxnino/tree-sitter-zig`
Updating git repository `https://github.com/lapce/psp-types`
Updating git repository `https://github.com/lapce/wasi-experimental-http`
error: failed to select a version for the requirement `interprocess = "^1.2.0"`
candidate versions found which didn't match: 1.1.1, 1.1.0, 1.0.1, ...
location searched: crates.io index
required by package `lapce-data v0.2.0 (/usr/home/nunotex/Work/freebsd/ports/editors/lapce/work/lapce-0.2.0/lapce-data)`
Any clues?
@nunotexbsd, I'm fairly sure that's an oversight with the manifest configuration that I suggested above. This might be due to the fact that I've been keeping up the habit of only bumping the version upon release, admittedly with no particular good reason (I used to think it makes the Git log nicer to read), which means that version 1.2.0, which the changes and fixes are set to be released as, does not exist in any shape or form from Cargo's perspective, since there isn't a Cargo.toml
for Interprocess that has version = "1.2.0"
anywhere.
Using version 1.1.1 in the [dependencies]
section while still overriding it using the patch table should work, I believe (simply replace interprocess = "1.2.0"
with interprocess = "1.1.1"
). Alternatively, you can just specify it as a Git dependency, without patching (if you resort to that, please let me know, because that'd mean that I severely misunderstand Cargo's dependency replacement machinery).
@kotauskas, thanks for the hints. The problem here is that I'm working inside FreeBSD ports framework and not learned yet how to tweak rust settings like the above because it implies updating Cargo.lock, etc. I will use manual patching for now because it's easier until a new version is out.
Thanks
I have finally set up a FreeBSD virtual machine, in which I will now manually test every single Interprocess release that makes it to Crates.io. Since the current latest commit, c66891d
, now builds correctly on FreeBSD with only a few warnings related to a work-in-progress related to FreeBSD-specific features, I believe this issue can now be closed.
If the final release of 2.0.0 or any later Crates.io version fails to compile on FreeBSD, please open a new issue much like this one!