macports-libcxx: sync with the latest compatible version of LLVM

[aeiouaeiouaeiouaeiouaeiouaeiou]

Bitcoin 27.0 now uses the std::bit_width function, which was only properly ​implemented in LLVM 12.

​https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/228575/steps/install-port/logs/stdio

In file included from addrman.cpp:10:
In file included from ./addrman.h:9:
In file included from ./netaddress.h:11:
./random.h:207:25: error: no member named 'bit_width' in namespace 'std'
        int bits = std::bit_width(range);
                   ~~~~~^

Also more:

In file included from addrdb.cpp:10:
In file included from ./addrdb.h:10:
./util/fs.h:65:30: error: no matching constructor for initialization of 'const std::u8string &' (aka 'const basic_string<char8_t> &')
        const std::u8string& utf8_str{std::filesystem::path::u8string()};
                             ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/include/libcxx/v1/string:791:40: note: candidate constructor not viable: no known conversion from 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char>>') to 'const allocator_type' (aka 'const std::allocator<char8_t>') for 1st argument
    _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a)
                                       ^

[kencu (Ken)]

just a heads-up that libcxx makes no attempt to maintain compatibility between versions. Requests to upstream to maintain object layouts to maintain compatibilty between libcxx versions have been declined — it’s not something they want to have to support.

I chose the libcxx from clang-11 to be the one used in macports-libcxx so as to try to be the most compatible with the libcxx installed in the system on the needed systems.

When/if macports-libcxx is inevitably updated, it is quite possible more ABI incompatibilities might creep in, much like what happened with gcc and libstdc++. Some testing will be needed. We have seen a few minor ABI issues already using the macports-libcxx we have, but all-in it’s been more successful than I had expected. That might change.

[ryandesign (Ryan Carsten Schmidt)]

In 95ed572ed41ddeee83862ea69715d80d18d2e993/macports-ports (master):

bitcoin: Requires macOS 10.15 or later

See: #69805

[barracuda156]

Replying to ryandesign:

In 95ed572ed41ddeee83862ea69715d80d18d2e993/macports-ports (master):

bitcoin: Requires macOS 10.15 or later

See: #69805

This apparently has nothing to do with macOS version, but has to check instead for C++ runtime.

[barracuda156]

36-25% port -v installed bitcoin
The following ports are currently installed:
  bitcoin @27.1_0+daemon+wallet (active) requested_variants='' platform='darwin 10' archs='ppc' date='2024-08-01T06:44:36+0800'

No hacks used, it just builds.

[aeiouaeiouaeiouaeiouaeiouaeiou]

Replying to barracuda156:

No hacks used, it just builds.

What it shows when you run otool -L $(which bitcoin)?

I had an idea to blacklist every Clang for darwin < 19. Despite the undesirability of this solution GCC uses its own libc++ implementation and I think this is the only way to use the bleeding edge C++20 functionality on legacy systems.