Merge bitcoin/bitcoin#22646: build: tighter Univalue integration, remove `--with-system-univalue`

0f95247246344510c9a51810c14c633abb382e95 Integrate univalue into our buildsystem (Cory Fields)
9b49ed656fb2b687fbbe8a3236d18285957eee16 Squashed 'src/univalue/' changes from 98fadc0909..a44caf65fe (fanquake)

Pull request description:

  This PR more tightly integrates building Univalue into our build system. This follows the same approach we use for [LevelDB](https://github.com/bitcoin-core/leveldb/), ([`Makefile.leveldb.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.leveldb.include)), and [CRC32C](https://github.com/bitcoin-core/crc32c) ([`Makefile.crc32c.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.crc32c.include)), and will be the same approach we use for [minisketch](https://github.com/sipa/minisketch); see #23114.

  This approach yields a number of benefits, including:
  * Faster configuration due to one less subconfigure being run during `./configure` i.e 22s with this PR vs 26s
  * Faster autoconf i.e 13s with this PR vs 17s
  * Improved caching
  * No more issues with compiler flags i.e https://github.com/bitcoin/bitcoin/pull/12467
  * More direct control means we can build exactly the objects we want

  There might be one argument against making this change, which is that builders should have the option to use "proper shared/system libraries". However, I think that falls down for a few reasons. The first being that we already don't support building with a number of system libraries (secp256k1, leveldb, crc32c); some for good reason. Univalue is really the odd one out at the moment.

  Note that the only fork of Core I'm aware of, that actively patches in support for using system libs, also explicitly marks them as ["DANGEROUS"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1430) and ["NOT SUPPORTED"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1312). So it would seem they exist more to satisfy a distro requirement, as opposed to something that anyone should, or would actually use in practice.

  PRs like #22412 highlight the "issue" with us operating with our own Univalue fork, where we actively fix bugs, and make improvements, when upstream (https://github.com/jgarzik/univalue) may not be taking those improvements, and by all accounts, is not currently actively maintained. Bitcoin Core should not be hamstrung into not being able to fix bugs in a library, and/or have to litter our source with "workarounds", i.e #22412, for bugs we've already fixed, based on the fact that an upstream project is not actively being maintained. Allowing builders to use system libs is really only exacerbating this problem, with little benefit to our project. Bitcoin Core is not quite like your average piece of distro packaged software.

  There is the potential for us to give the same treatment to libsecp256k1, however it seems doing that is currently less straightforward.

ACKs for top commit:
  dongcarl:
    ACK 0f95247246 less my comment above, always nice to have an include-able `sources.mk` which makes integration easier.
  theuni:
    ACK 0f95247246344510c9a51810c14c633abb382e95. Thanks fanquake for keeping this going.

Tree-SHA512: a7f2e41ee7cba06ae72388638e86b264eca1b9a8b81c15d1d7b45df960c88c3b91578b4ade020f8cc61d75cf8d16914575f9a78fa4cef9c12be63504ed804b99

1 files changed, 1 insertions, 1 deletions

diff --git a/contrib/guix/libexec/build.sh b/contrib/guix/libexec/build.sh
index 93476d5f30..e009f97c60 100755
--- a/contrib/guix/libexec/build.sh
+++ b/contrib/guix/libexec/build.sh
@@ -297,7 +297,7 @@ mkdir -p "$DISTSRC"
                     ${HOST_CXXFLAGS:+CXXFLAGS="${HOST_CXXFLAGS}"} \
                     ${HOST_LDFLAGS:+LDFLAGS="${HOST_LDFLAGS}"}
 
-    sed -i.old 's/-lstdc++ //g' config.status libtool src/univalue/config.status src/univalue/libtool
+    sed -i.old 's/-lstdc++ //g' config.status libtool
 
     # Build Bitcoin Core
     make --jobs="$JOBS" ${V:+V=1}