rizin
rizin copied to clipboard
Bad pkg-config files in the official `static-x86_64` release artifacts
Issue summary
pkg-config files distributed in the official static-x86_64
releases contain wrong hard-coded paths.
This makes it impossible to build software against rizin libs out-of-the-box, which notably breaks plugin installation/build (at least in the case of rz-ghidra
).
I did not test with the latest git release as this is a problem with the release artifacts.
Work environment
Questions | Answers |
---|---|
OS/arch/bits (mandatory) | Ubuntu 21.04 amd64 |
File format of the file you reverse (mandatory) | Not applicable |
Architecture/bits of the file (mandatory) | Not applicable |
rizin -v full output, not truncated (mandatory) |
rizin 0.3.0 @ linux-x86-64 commit: be157e869c4e71419433dfcbe838dfa8f828c597, build: 2021-09-24__12:59:49 (obtained from https://github.com/rizinorg/rizin/releases/download/v0.3.0/rizin-v0.3.0-static-x86_64.tar.xz) |
Expected behavior
pkg-config files are correct.
Actual behavior
- All 25 pkg-config files under
lib/pkgconfig
have theprefix
key set to the value/github/home/rizin-static
. -
rz_socket.pc
andrz_util.pc
contain/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/libutil.a
in the value of theLibs
key. - It is possible there are more errors, but I did not check more thoroughly.
Steps to reproduce the behavior
- Examine the pkg-config files in the release artifacts.
Example of a failed plugin build due to this problem:
- Install the files under
/usr/local
-
$ rz-pm init && rz-pm update && rz-pm -ci rz-ghidra
Additional info
-
About the hard-coded value of
prefix
:The folder structure of the release tarball makes it seem like one is supposed to place the contents under
/usr/local
, which is the most common location for system-wide installations of software not managed by the system package manager, and is on the$PATH
by default on many distros.However, the pkg-config files provided in the release tarball are broken for this assumed use case. Furthermore, a user might want to choose a different prefix other than
/usr/local
, so simply replacing/github/home/rizin-static
with/usr/local
may not be a complete solution, though it is an acceptable stop-gap measure.
Perhaps the release tarballs should include a simple installation script that lets the user choose the installation prefix, and rewrites the appropriate files accordingly.
-
About
/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/libutil.a
Sounds like a problem with the CI/release automation setup.
Thanks for the report!
I'm not sure about this, because the -static binaries are compiled so that they are "portable", meaning that you can use them everywhere, without us knowing where the user is going to install it.
Having an install script for the -static binaries might be a friction, where instead that release build is supposed to be easily deployed/used. Also, inside that artifact you can only find .a
libs (statically built ones) but usually one would want to use dynamically built libraries to compile other plugins/stuff.
Opinions @thestr4ng3r @wargio @kazarmy ?
I'm looking at --define-prefix
option. Not sure if it matters. Just noticing it here.
The prefix
of the .pc
files seems to be easily replaceable by using --define-prefix
, the problem with libutil.a instead seems to be something else. I can find it also in a regular build files,where Libs.private
uses the full path of libutil.so.
For the libutil issue, I've opened an issue for meson, I believe it's a problem there: https://github.com/mesonbuild/meson/issues/9301
I'm looking at
--define-prefix
option. Not sure if it matters. Just noticing it here.
The
prefix
of the.pc
files seems to be easily replaceable by using--define-prefix
That would work if you can pass flags to the invocation of pkg-config, but how can one do that when installing a plugin from the repository (for example, $ rz-pm -ci rz-ghidra
, as above)?
Also, inside that artifact you can only find
.a
libs (statically built ones) but usually one would want to use dynamically built libraries to compile other plugins/stuff.
because the -static binaries are compiled so that they are "portable", meaning that you can use them everywhere
So how does usage of rz-pm
factor into this? Installation of plugins requires building them.
Still, after correcting the pkg-config errors mentioned in the OP and temporarily chmod 777 /usr/local/lib/pkgconfig /usr/local/include
, I managed to execute $ rz-pm -ci rz-ghidra
successfully.
The chmod workaround is a solution for another issue - some steps of the installation may require installation to system directories for which the process might not have the required permissions, so it fails.
At the end of the day, it seems to be simply calling cmake --install builddir
or equivalent, so unless that command is executed with the required permissions, some files will fail to install, failing the whole installation.
Of course running the whole plugin installation under sudo
would also solve this but that is not a good solution.
EDIT: My suspicion was correct: https://github.com/rizinorg/rizin-pm/blob/c5520b12c0a6e680a1418dbfe242561f1582d897/db/rz-ghidra#L14
Maybe changing this to something like ${MAKE} install || echo "Install failed; try again with sudo?" ; sudo ${MAKE} install || exit 1
could work.
That would work if you can pass flags to the invocation of pkg-config, but how can one do that when installing a plugin from the repository (for example, $ rz-pm -ci rz-ghidra, as above)?
That I don't know yet :) I'm just trying to gather information here so that we can reach a good outcome.
I think what can be done is to have rz-pm
write temporary .pc
files into a temp directory somewhere, and then prepend the directory to PKG_CONFIG_PATH
(idea from https://github.com/Homebrew/legacy-homebrew/issues/44272#issuecomment-142774886). Not sure whether this is the best or only option.
Yeah I was thinking the same about having rz-pm rewriting the .pc files in case the build is compiled with RZ_IS_PORTABLE set to 1. We'd also need to resolve the problem with libutil from meson.
This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has probably changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of rizin. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.
For now, nothing to do here... Let's see if at some point we can use https://mesonbuild.com/Builtin-options.html#pkgconfig-module .