Build system should allow emulator binary to use its own shared library
Exact requirements
The project should have a build mode where the binary takes the emulator code from its shared library instead of duplicating the code. This reduces the package size when distributions install both the library and the emulator.
Suggested solution
This should be a trivial adjustment to the build system.
Also note that you probably want to set the soname in the installed library and use so versionning.
It is nice feature to have for sure, though some APIs used by the binary are not exposed as public symbols in the lib yet (Infrastructure stuff like logger, argparser). This will need to be sorted out to be able to link to lib properly.
Looking forwards to some progress in this regard.
@clausecker What is the actual advantage of this approach? It will not save you gigabytes (or even hundreds of megabytes or so). Currently, rvvm+librvvm binaries weights less than 1M, so... Just, for what purpose? What is the advantage?
Especially when you consider that nowadays people, on the contrary, are moving away from dynamic linking as much as possible for obvious reasons...
RVVM is not QEMU, which weighs >4M (and for all architectures ~120M).
With the new overhauled build system, it is now possible to build RVVM CLI binary against shared librvvm.
You need to pass USE_LIB_SHARING=1 to make.
By default the new build system still links against project-owned libraries statically, for following reasons:
- I don't want my development builds end up confusing system
librvvmand the one I just built - Binary may end up being distributed separately if we aren't installing it system-wide
- Some supported platforms (WASM, Redox, DOS) do not support dynamic linking
Distribution packaging systems supposedly should have no issue setting USE_LIB_SHARING=1 in env when building the package.
Build system sets LD_LIBRARY_PATH to the release directory for it's subprocesses, so tests will run with the correct librvvm library even in the presence of system-wide one.
Works fine for me.
Looking forwards to a new release with the updated build system!
Is the tag v0.7-git meant to be the 0.7 release?
It's a base tag for the build system to determine a "git" version, i.e. one that hasn't been released yet