Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ln: /usr/bin/pbqff: Operation not permitted (macOS) #294

Closed
isolated-matrix opened this issue Aug 9, 2024 · 4 comments
Closed

ln: /usr/bin/pbqff: Operation not permitted (macOS) #294

isolated-matrix opened this issue Aug 9, 2024 · 4 comments

Comments

@isolated-matrix
Copy link

Back again!

MacPorts finally updated their version of Rust so I have been able to install pbqff somewhat successfully. I was not able to use make install to compile pbqff because this error came up:

make: *** No rule to make target `target/release/pbqff', needed by `install'.  Stop.

However, I was able to install it using the command sudo cargo build --features vers --release (it wouldn't install without sudo; an error said that some permission or other had been denied).

I then tried to follow up with the next commands, and further errors popped up. These are the errors that I am posting about. When I tried entering the command sudo ln -sf $(realpath target/release/pbqff) /usr/bin/pbqff, I ended up getting an error saying:

ln: /usr/bin/pbqff: Operation not permitted

The same thing happened with qffbuddy. After a quick search, I think I found the reason. It turns out that, after one of the OS updates, apple decided that they would prevent anyone from messing with some of the core parts of the OS, including most of /usr/ (see this post on Stack Overflow).

It looks like the solution is to simply change the command to:

sudo ln -sf $(realpath target/release/pbqff) /usr/local/bin/pbqff

The program I compiled myself works perfectly this way.

There is only one other problem. Executing the command sudo cp $< $(MANPATH)/pbqff.1 leads to an error saying zsh: no such file or directory: /pbqff.1 ($MANPATH is the Mac equivalent of $MANDIR). I'm not quite sure how to fix this one, because I don't know what the pbqff.1 directory/file is (or where to find it).

In summary, I've managed to get the program running, but the commands for making the symbolic links need to be changed slightly to work on Mac. And, if you know why the final command is not working, I'd be happy to test out any ideas you might have to make it work!

@ntBre
Copy link
Owner

ntBre commented Aug 9, 2024

Awesome, thanks for the followup! For the first issue, I think I just need to add an explicit rule to build target/release/pbqff. That's actually a little frightening because it means anytime I was running make install in the past, I was essentially getting a random version, whatever was currently in target/release instead of rebuilding each time.

Beyond that issue, I think the best practice here is to have some kind of INSTALL_PATH variable so users can switch away from /usr/bin. That would give a command like make install INSTALL_PATH=/usr/local/bin in your case, I think.

For the final command, if you're running sudo cp $< $(MANPATH)/pbqff.1 in your terminal instead of in make, $< and $(MANPATH) will both expand to nothing, which I think would explain the error message (the full command would just be sudo cp /pbqff.1). These are special make variables, not shell variables, although they look very similar! The file in the repo is actually rpbqff.1, so I might need to update the paths in general.

I'm going to try to add an installation workflow to the GitHub CI to make sure this stuff stays current with the rest of the repo in the future. Thanks again for testing all of this out and submitting these reports!

@isolated-matrix
Copy link
Author

Ah... it shouldn't be too bad, though, because most things that you've adjusted recently are for compilation purposes (not fixing bugs in the programs), right? So long as it runs, the results should be fine...?

The INSTALL_PATH might be a good way to go—saves confusion for people in future.

So to install the man entry I should just enter the command sudo cp /pbqff.1?

@ntBre
Copy link
Owner

ntBre commented Aug 12, 2024

Yeah that's true, and I don't actually run any real calculations on my desktop anyway. The recipe for deploying to our cluster has definitely been updating the binary.

I just merged #295, which, despite the name, also included changes to the Makefile and to the repository README. You should be able to use the install.full recipe like this now:

make install.full PREFIX=/usr/local/bin MANDIR=/usr/local/share/man/man1

I switched the plain install recipe just to run cargo install, I think after your last issue. I went with PREFIX instead of INSTALL_PATH or something similar just because I think I've seen it called a prefix elsewhere. Double-check that MANDIR too, but I think that should work based on some searching I did online.

So to install the man entry I should just enter the command sudo cp /pbqff.1?

Ah, no, I should have been more clear there. That's the erroneous expansion of the sudo cp $< $(MANPATH)/pbqff.1 command. $< and $(MANPATH) are supposed to be defined in the Makefile, so it should expand into a normal cp command like cp man/rpbqff.1 /usr/local/share/man/man1/pbqff.1, but those variables are not defined in the shell itself, leading to the error message you got. Anyway, I think install.full should now take care of this for you!

@isolated-matrix
Copy link
Author

isolated-matrix commented Aug 13, 2024

I reinstalled it with the updated files, and it works perfectly (including the man entry)!

I'm going to make a separate issue for something I've found in qffbuddy, but I will close this issue now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants