Support building internal libraries as shared. This reduces
development time by eliminating the need to re-link all
binaries every time non-interface code in the library changes.
Instead, can hack on libxyz, then `make libxyz`, and re-run
monerod.
By default BUILD_SHARED_LIBS is OFF in release build type,
and ON in debug build type, but can be overriden with -D.
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.
Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).
This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
We keep 1, 2, 3 multipliers till the fee decrase from 0.01/kB
to 0.002/kB, where we start using 1, 20, 166 multipliers.
This ensures the higher multiplier will compensate for the
block reward penalty when pushing past 100% of the past median.
The fee-multiplier wallet setting is now rename to priority,
since it keeps its [0..3] range, but maps to different multiplier
values.
This adds [snap](https://snapcraft.io) packaging to the project. See the
link for more information on snaps. Snap packages install on all Linux
distributions. On Ubuntu, snap confinement with apparmor and seccomp
provide an additional layer of security.
This snap sets up monerod as a systemd service, which should start
immediately on install. To access the wallet CLI, simply run `monero`
(/snap/bin/monero). I think it's a really quick & easy way to get
started with monero.
I've made some opinionated decisions in the packaging just to kick this
off, but I'm happy to iterate on this stuff.
This was disabled earlier as part of diagnosing failing tests
on ARM, which turned out to be due to aliasing, fixed by
adding -fno-strict-aliasing. So, re-enabling it back.
32-bit build would fail to link with 'mdb_env_create undefined' (because
for 32-bit build, mdb_env_create_vl32 is defined instead).
This bug was introduced with the recent change to virtual object
libraries. The problem is that the COMPILE_DEFINITIONS property
was not propagated from dependee target (lmdb) to depedent
target's (blockchain_db) virtual object lib (obj_blockchain_db).
This patch makes that happen.
I chose to include INTERFACE_COMPILE_DEFINITIONS because there
should not be a need to propagate private defs, but it doesn't
make a difference in this case.
