libc++ on PowerPC: highly experimental, but working setup

[barracuda156]

To be clear, this is not meant for regular users or regular use as the main system. For this reason packaged installers are not provided, so that nobody installs this by accident.
It is still unknown how far this can go, especially given that the current version of libc++ we have is from LLVM 7, which is old. Still, this is much better than what MacPorts has on Snow Leopard x86 by default. Also, AFAICT, the setup is usable normally, not at “we can compile Hello World” level.

Switching to libc++ does not make the system strictly better off. In fact, 10.6 / libstdc++ on powerpc has arguably more stuff working than 10.6 / libc++ on x86. It does, however, solve some specific issues, and may work better with software which heroically assumes that Apple = libc++.

There is no straight-forward way to bootstrap libc++-based installation at the moment, since to build against libc++ we need gcc supporting -stdlib= flag, and gcc itself has dependencies which use C++. It seems to work fine, however, to install the basic toolchain and then use it to upgrade its dependencies, and build everything further directly for libc++.

Very rough sketch of provisionally working procedure:

1. Install gcc10-bootstrap.
2. Install libcxx-powerpc in default variant (provides headers for gcc14-libcxx).
3. Build dependencies for gcc14, install libgcc14 and gcc14 with +stdlib_flag variant. I have normally been using cctools and ld64 built against llvm-powerpc port (LLVM 7 with minor tweaks), which it the default in PowerPC Ports, but it should not matter much, other options should work too. darwin-xtools can also be used to provide both cctools and ld64 components, though this is far less tested (by me).
4. Reinstall libcxx-powerpc into the system prefix via +default_runtime. I could not make +emutls work correctly today, so perhaps for now use libcxx-powerpc +default_runtime -emutls.
5. Drop arch restriction in MacPorts base, so that cxx_stdlib choice is used for setting cxx- and ldflags.
6. Set cxx_stdlib to libc++ in macports.conf, set default_compiler to macports-gcc-14.
7. Rebuild cctools and ld64 against libc++. I have used darwin-xtools at this stage, because llvm failed to build against its own libraries. darwin-xtools work fine, at least v. 1.1.0. Do not use mainstream port, use port from here.
8. Perhaps rebuild w/e MacPorts wants of dependencies.
9. Have fun.

Known issues:

1. Some portfiles have wrong settings which break building them (I have fixed some, but I am sure there are many more). If correct flags are not passed automatically, it may not be a fault of a port, but rather an incorrect condition in portfile. Worth checking that before debugging the build.
2. Legacysupport hack for clangs to provide newer C++ runtime is done in a way which cannot work with gcc. I have fixed that in my fork (in a sense it does not break the build anymore).
3. Setting default_compiler to gcc14 leads to everything being built by default with it, including pure C ports. This is probably good, but may not always work. I would not expect perl and db48 to have bugs breaking compilation with a modern gcc, but here we are.
   https://trac.macports.org/ticket/71915
   https://trac.macports.org/ticket/71913
   In such cases compiler can be forced to gcc-4.2, which builds them fine.
4. LLVM 7 fails to build: https://trac.macports.org/ticket/71919
   Build error against libc++: type_traits: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' iains/LLVM-7-branch#5

[barracuda156]

Some port are here: http://macos-powerpc.org/packages_libcxx

A lot of stuff is unrelated to C++, since MacPorts requires a separate archive per stdlib, so pure C ports cannot be fetched from the regular one, however it has ICU, CMake and darwin-xtools (built against libc++). I am not planning to build thousand of ports here as well in parallel to libstdc++-based ones, but I will likely try some more complex stuff.

P. S. @RJVB @catap @Jazzzny @cooljeanius Looks like we can use libc++ on powerpc with minimal tweaks to the setup.
Any idea whether it will take much to upgrade it to a newer one? There is no need for clang or even llvm as such, only C++ runtime.

[RJVB]

P. S. @RJVB @catap @Jazzzny @cooljeanius Looks like we can use `libc++` on powerpc with minimal tweaks to the setup. Any idea whether it will take much to upgrade it to a newer one?

No idea. But what's the point? You observed as well as I did that libc++ requires more ressources to build and mostly runs slower than libstdc++ .

[barracuda156]

But what's the point? You observed as well as I did that libc++ requires more ressources to build and mostly runs slower than libstdc++ .

Avoid malloc hell where it happens :)
What I think is that it might work better for a browser, for example, and that can have its bundled library. Other than that just because we can. It is more of an experiment than a plan.

[RJVB]

Avoid malloc hell where it happens :)

? Malloc is not a C++ function...

What I think is that it might work better for a browser, for example, and that can have its bundled library.

Some browsers do bundle libc++ (or rather, link to their own static copy) but that's more so they can support "old" Mac OS versions and still use C++2001+ . The GCC team strive for backwards compatibility of old OS versions and hardware, the LLVM project is just about the opposite. Both can have errors on platforms that aren't the main ones on which they're used, but unless you're looking for extra work and/or incomprehensible crashes I'd stick with the platform C++ runtime (AFAIK libstdc++ for PPC).

[barracuda156]

? Malloc is not a C++ function...

Those error happen due to existence of two libstdc++ in the system, and symbols may not resolve correctly always. I am not saying this should be exclusive to C++, but it is a common case.
Often it is more of less harmless, sometimes breaking.

Recent example of what I am talking about: iains/darwin-xtools#11
But there are a lot, on Trac also.