decomp library not found #1

themadbit commented 2025年09月12日 11:41:10 +02:00

Building the plugin searches the decomp library. However, reoxide provides the following in the bin directory:

-r-xr-xr-x 1 root root 265K 1970年01月01日 03:00 decompile
-r-xr-xr-x 1 root root 261K 1970年01月01日 03:00 libcore.so
-r-xr-xr-x 1 root root 5.9M 1970年01月01日 03:00 libreoxide.so

Am I getting it wrong?

Building the plugin searches the `decomp` library. However, `reoxide` provides the following in the bin directory: ```shell -r-xr-xr-x 1 root root 265K 1970年01月01日 03:00 decompile -r-xr-xr-x 1 root root 261K 1970年01月01日 03:00 libcore.so -r-xr-xr-x 1 root root 5.9M 1970年01月01日 03:00 libreoxide.so ``` Am I getting it wrong?

cluosh commented 2025年09月12日 11:49:03 +02:00

Are you using the dev branch when building against main of reoxide? Since this is template repository, I wanted to make sure that the main branch here tracks the stable releases of reoxide. I'm up for suggestions how to make this nicer, I guess we could have a dev branch in the main reoxide repo as well 😅

Are you using the `dev` branch when building against `main` of reoxide? Since this is template repository, I wanted to make sure that the `main` branch here tracks the stable releases of reoxide. I'm up for suggestions how to make this nicer, I guess we could have a dev branch in the main reoxide repo as well 😅

themadbit commented 2025年09月12日 11:56:12 +02:00

I am using main against main. main branch of reoxide, builds decompile and the main of plugin checks decomp. Not sure the main here is tracking the main at reoxide :) . I am using the latest main for both

I am using `main` against `main`. main branch of reoxide, builds `decompile` and the main of plugin checks `decomp`. Not sure the main here is tracking the main at reoxide :) . I am using the latest main for both

cluosh commented 2025年09月12日 12:49:51 +02:00

Ah yes that is what i meant. If you use dev from here and build against main of reoxide it should build (there is a warning regarding this in the readme)

Ah yes that is what i meant. If you use `dev` from here and build against `main` of reoxide it should build (there is a warning regarding this in the readme)

themadbit commented 2025年09月12日 13:03:53 +02:00

huh! my bad.
so the main here is time travelling 😄

huh! my bad. so the main here is time travelling 😄

themadbit commented 2025年09月12日 15:54:51 +02:00

I got it building. I'm just curious why building it requires reoxide to be present. Because it can only be applicable for use with reoxide?
Can we also have pre-built plugin libraries as part of the reselease?

I got it building. I'm just curious why building it requires reoxide to be present. Because it can only be applicable for use with reoxide? Can we also have pre-built plugin libraries as part of the reselease?

cluosh commented 2025年09月12日 17:17:51 +02:00

Building it requires reoxide to be present, because the plugins need access to the internal Ghidra functionality, and it gets this by linking to libreoxide.so (which contains all of the necessary Ghidra functions as well as the reoxide communication wrappers). Because Ghidra is written in C++ we need to make sure the plugin ABI matches the ABI of the compiled libreoxide.so. As far as I am aware, there are no specific guarantees we have besides "as long as you compile it with the same compiler and the same language standard, it should work".

For other Linux distributions, there is the dockerfile which compiles the plugin in manylinux2014, the same way we distribute reoxide to PyPI, therefore guaranteeing that we compile it with the same compiler as the public stable release of reoxide. When distributing on Nix, you can distribute it separately, as long as you use the same compiler for building reoxide and the plugins. It would therefore also be nice if we could provide Nix users a template on how they can compile plugins so that it matches the reoxide nix package.

Besides that, there is an experimental Rust API that is a subset of the C++ API. For Rust we added a C wrapper around the most commonly used methods, which gives us better ABI stability and also allows us to use different compilers. The plan is to evolve this wrapper into a nice, safe wrapper with good user experience, but as of now the C++ interface (this repository) is the main way to write plugins and it will be for the foreseeable future.

Building it requires reoxide to be present, because the plugins need access to the internal Ghidra functionality, and it gets this by linking to `libreoxide.so` (which contains all of the necessary Ghidra functions as well as the reoxide communication wrappers). Because Ghidra is written in C++ we need to make sure the plugin ABI matches the ABI of the compiled `libreoxide.so`. As far as I am aware, there are no specific guarantees we have besides "as long as you compile it with the same compiler and the same language standard, it should work". For other Linux distributions, there is the dockerfile which compiles the plugin in `manylinux2014`, the same way we distribute reoxide to PyPI, therefore guaranteeing that we compile it with the same compiler as the public stable release of reoxide. When distributing on Nix, you can distribute it separately, as long as you use the same compiler for building reoxide and the plugins. It would therefore also be nice if we could provide Nix users a template on how they can compile plugins so that it matches the reoxide nix package. Besides that, there is an experimental Rust API that is a subset of the C++ API. For Rust we added a C wrapper around the most commonly used methods, which gives us better ABI stability and also allows us to use different compilers. The plan is to evolve this wrapper into a nice, safe wrapper with good user experience, but as of now the C++ interface (this repository) is the main way to write plugins and it will be for the foreseeable future.

cluosh commented 2025年09月12日 17:22:26 +02:00

Also, the reoxide pip package contains the needed API header files. The reoxide command as used in meson.build is mainly used as convenience for finding the paths to the header files, the paths to the libreoxide.so and the installation directory for the plugin.

The real "necessary" part for building boils down to this part of the meson file:

Also, the `reoxide` pip package contains the needed API header files. The `reoxide` command as used in `meson.build` is mainly used as convenience for finding the paths to the header files, the paths to the `libreoxide.so` and the installation directory for the plugin. The real "necessary" part for building boils down to this part of the meson file: https://codeberg.org/ReOxide/plugin-template/src/commit/ef4856f1a4a146b6b07e5969ad60289f9ce47abd/meson.build#L23-L28