Unable to install in FreeBSD14.1

[souradeep100]

What happened cargo install is failing with libproc build

What I expected to happen cargo install of other crates are successful.

To Reproduce cargo install shpool

error: failed to compile shpool v0.7.0,

Compiling shpool-protocol v0.2.0 Compiling libproc v0.14.8 error[E0601]: main function not found in crate build_script_build --> /home/schakrabarti/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libproc-0.14.8/build.rs:23:13 | 23 | fn main() {} | ^ consider adding a main function to /home/schakrabarti/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libproc-0.14.8/build.rs

[ethanpailes]

I don't think we use libproc for too much, so we can probably condition this out for freebsd. For now, you can try seeing if 0.6.3 or 0.6.2 will build for you since I think we added libproc somewhat recently. You could also try reporting the issue upstream since libproc is supposed to be a cross platform crate.

[souradeep100]

Hi tried version 0.6.0 and following error during install was coming

Compiling termini v1.0.0 Compiling tempfile v3.12.0 Compiling shpool_vt100 v0.1.2 error: failed to run custom build command for motd v0.2.2

Caused by: process didn't exit successfully: /tmp/cargo-installZ58FUj/release/build/motd-61bbca1f94cea17d/build-script-build (exit status: 101) --- stdout cargo:rerun-if-changed=src/pam_motd_overlay.c cargo:rerun-if-changed=src/pam_motd_overlay_versions.ldscript

--- stderr thread 'main' panicked at /home/schakrabarti/.cargo/registry/src/index.crates.io-6f17d22bba15001f/motd-0.2.2/build.rs:23:13: build failed: error building overlay, code = exit status: 1 STDOUT: STDERR: ./src/pam_motd_overlay.c:11:10: fatal error: 'security/_pam_types.h' file not found

include <security/_pam_types.h>

       ^~~~~~~~~~~~~~~~~~~~~~~

1 error generated.

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace warning: build failed, waiting for other jobs to finish... error: failed to compile shpool v0.6.0, intermediate artifacts can be found at /tmp/cargo-installZ58FUj. To reuse those artifacts with a future compilation, set the environment variable CARGO_TARGET_DIR to that path. [schakrabarti@schakrabarti-freebsd4 ~]$

[ethanpailes]

That build issue should be fixed in later version. Does a version between 0.6.0 and 0.7.0 work for you?

[souradeep100]

No, none of them are getting installed. I guess there is some tight dependency for Linux here.

[ethanpailes]

Dang, sorry about that. I don't have FreeBSD box to test on, so if you are willing to try to do the port yourself I can do my best to give you pointers about where to start poking. If not, I'll try to allow building without libproc on freebsd and ping you to test it.

Actually, thinking about it a little, there might be a github action that I could use to try to iterate on builds on freebsd. Would probably be easier than trying to set up a VM on my local machine.

[souradeep100]

I will be happy to help you on bringing shpool in FreeBSD. You can share me pointers where to start looking. I will try to do my best.

[ethanpailes]

Awesome!

The only place we use libproc is here, so if you can condition that out that should probably fix the build issue. Ideally there is some way to map from pid to process name under freebsd so we could keep all the functionality in place, but if that proves too difficult you could disable the entire prompt prefix feature, since this shell sniffing is in support of that.

Even if shpool builds once you've done that, I suspect that it won't work at runtime on freebsd. The main issue is that we rely on /proc/<pid>/exe in a few other places. Elsewhere, in that same prompt.rs file we use it to self-exec. I've been meaning to fix this by plumbing argv[0] down to be able to self-exec in a more portable way, but I haven't gotten around to it yet.

We also use it in server.rs to do essentially the same thing that we are using libproc for. I think I wrote that code before I knew about libproc and have just never gotten around to updating it. Whatever solution you settle on for libproc you can apply here as well. This is only used to generate a warning, so it would also be entirely appropriate to just condition it out of the build for freebsd entirely. A little version skew between client and daemon is not a huge deal, especially now that we have made the client<->daemon protocol more forgiving of skew.