Bad pkg-config files in the official `static-x86_64` release artifacts

[FranciscoPombal]

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 the prefix key set to the value /github/home/rizin-static.
• rz_socket.pc and rz_util.pc contain /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/libutil.a in the value of the Libs 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.

[ret2libc]

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 ?

[ret2libc]

I'm looking at --define-prefix option. Not sure if it matters. Just noticing it here.

[ret2libc]

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.

[ret2libc]

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

[FranciscoPombal]

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)?

[FranciscoPombal]

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.

[ret2libc]

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.

[kazarmy]

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.

[ret2libc]

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.

[ret2libc]

For now, nothing to do here... Let's see if at some point we can use https://mesonbuild.com/Builtin-options.html#pkgconfig-module .