util: Work around ParseHex gcc cross compiler bug

[maflcko]

I fail to see how an explicit ParseHex template instantiation fails to also instantiate TryParseHex.

Nonetheless, to work around a compiler bug, change the explicit instantiation from ParseHex to TryParseHex. (ParseHex is inline anyway and will be instantiated by the compiler either way).

Fixes #25227 (comment) :

  CXXLD    bitcoind
/usr/lib/gcc-cross/powerpc64le-linux-gnu/11/../../../../powerpc64le-linux-gnu/bin/ld: libbitcoin_node.a(libbitcoin_node_a-net_processing.o): in function `(anonymous namespace)::PeerManagerImpl::ProcessMessage(CNode&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, CDataStream&, std::chrono::duration<long, std::ratio<1l, 1000000l> >, std::atomic<bool> const&)':
net_processing.cpp:(.text+0x29660): undefined reference to `std::optional<std::vector<unsigned char, std::allocator<unsigned char> > > TryParseHex<unsigned char>(std::basic_string_view<char, std::char_traits<char> >)'
/usr/lib/gcc-cross/powerpc64le-linux-gnu/11/../../../../powerpc64le-linux-gnu/bin/ld: libbitcoin_node.a(libbitcoin_node_a-rest.o): in function `rest_getutxos(std::any const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
rest.cpp:(.text+0x83b4): undefined reference to `std::optional<std::vector<unsigned char, std::allocator<unsigned char> > > TryParseHex<unsigned char>(std::basic_string_view<char, std::char_traits<char> >)'
/usr/lib/gcc-cross/powerpc64le-linux-gnu/11/../../../../powerpc64le-linux-gnu/bin/ld: libbitcoin_node.a(libbitcoin_node_a-torcontrol.o): in function `std::vector<unsigned char, std::allocator<unsigned char> > ParseHex<unsigned char>(std::basic_string_view<char, std::char_traits<char> >)':
torcontrol.cpp:(.text._Z8ParseHexIhESt6vectorIT_SaIS1_EESt17basic_string_viewIcSt11char_traitsIcEE[_Z8ParseHexIhESt6vectorIT_SaIS1_EESt17basic_string_viewIcSt11char_traitsIcEE]+0x2c): undefined reference to `std::optional<std::vector<unsigned char, std::allocator<unsigned char> > > TryParseHex<unsigned char>(std::basic_string_view<char, std::char_traits<char> >)'
/usr/lib/gcc-cross/powerpc64le-linux-gnu/11/../../../../powerpc64le-linux-gnu/bin/ld: libbitcoin_common.a(libbitcoin_common_a-external_signer.o): in function `ExternalSigner::SignTransaction(PartiallySignedTransaction&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)':
external_signer.cpp:(.text+0x8d84): undefined reference to `std::optional<std::vector<unsigned char, std::allocator<unsigned char> > > TryParseHex<unsigned char>(std::basic_string_view<char, std::char_traits<char> >)'
collect2: error: ld returned 1 exit status

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	hebasto, gruve-p

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

[maflcko]

To test on a fresh install of Ubuntu/Debian with gcc-11 or later: #25227 (comment)

[hebasto]

ACK fa8481b, tested on Ubuntu 22.04, gcc 11.3 for the riscv64-linux-gnu host.,

[gruve-p]

ACK fa8481b

Tested cross compiling through depends on Ubuntu Jammy (22.04) with GCC 11 on these hosts:
i686-pc-linux-gnu
x86_64-pc-linux-gnu
x86_64-w64-mingw32
x86_64-apple-darwin
arm64-apple-darwin
arm-linux-gnueabihf
aarch64-linux-gnu
powerpc64-linux-gnu
powerpc64le-linux-gnu
riscv32-linux-gnu
riscv64-linux-gnu
s390x-linux-gnu

[fanquake]

Does anyone have a link to an upstream issue? Is this a regression in GCC 11, that has been fixed in 12/13?

[maflcko]

It is not fixed in gcc-12, see #25227 (comment). gcc-13 exists, so it may be possible to test. I have not attempted to reduce the test case, nor did I dig deeper to find out if this is a compiler bug or bug in our code, because I don't think we have a choice here: If there are two equivalent versions of the same code, but one doesn't compile, we should pick the one that compiles.

[maflcko]

To clarify, even if the workaround is not needed in gcc-13 or gcc-14, I think we shouldn't revert it. I see it as a permanent workaround.

[fanquake]

gcc-13 exists, so it may be possible to test.

Still broken in GCC 13.0.1. riscv64-linux-gnu-g++-13 13.0.1 20230215