libcxx and gcc11/gcc12

[barracuda156]

@iains Could you please say how libcxx can be used with gcc11? (And will it even work for PowerPC?)

@kencu mentions it here: https://trac.macports.org/ticket/64932

A new feature however, that might be of use, is that libc++ can in fact be used from gcc11 now (Iain’s repos, at least).

I have also found a rather old news referring to your patch: https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-libcpp-LLVM-Support

[iains]

From GCC-11 (and earlier with a suitable back port), it is possible to configure the compiler to accept -stdlib=

• This is intended to help on systems 10.8+ where the default C++ runtime is libc++.
• It requires that the configurer installs a suitable set of libc++ headers and then points to those in the configuration process.

---

For earlier systems, IFF one can build a reliable libc++ for the platform, then it will also be possible to use the configuration option there.

It will be essential to configure the libc++ build so that it makes use of the libc++abi from the existing libstd++ and also the unwinder from /usr/libSystem (10.6,) or /usr/lib/libgcc_s.1.dylib (10.4 10.5).

Actually, on 10.7 there is very little that uses /ust/lib/libstdc++.dylib - it's more likely to be 3rd party stuff than anything on the system), so it will probably be quite smooth there.

---

powerpc-darwin{8,9}:
I recall that (the last time I looked at this was ≈ llvm-7-ish) that libc++ needed a few patches to work on powerpc (when built with GCC) .. of course, building with clang is not really viable owing to the well-documented work To Be Done in finishing off the powerpc darwin clang port).

So .. IFF you:

• make the patches ( I think a lot to do with long double constexpr problems)
• build libc++ with GCC
• and make sure that the build does not create more conflicts in library versioning (by forwarding the ABI and unwinder as needed)

... then I guess it will work...
it is one work-around for the libstdc++ symbol clashes on darwin9 (but there is a better solution which is to version libstdc++ symbols there)

[barracuda156]

@iains Thank you for the explanation!
This sounds like well beyond my level of expertise atm, unfortunately. I may be able to do some patches when I see what fails, but I do not know the internal logic of OS, compiler and libc interaction to correct for issues you mention (like long double constexpr).

Building libcxx (in a sense that compilation went through completion) for ppc wasn’t too hard, I just had to add ppc ppc64 in buildit scripts and remove a couple of flags which gcc didn’t get: https://trac.macports.org/ticket/64932

36-109:libcxx svacchanda$ lipo -info /Users/svacchanda/Dev/libcxx/usr/lib/libc++abi.dylib 
Non-fat file: /Users/svacchanda/Dev/libcxx/usr/lib/libc++abi.dylib is architecture: ppc7400
36-109:libcxx svacchanda$ lipo -info /Users/svacchanda/Dev/libcxx/usr/lib/libc++.1.dylib 
Non-fat file: /Users/svacchanda/Dev/libcxx/usr/lib/libc++.1.dylib is architecture: ppc7400

(So +universal has been ignored, but that’s a secondary concern, of course.)
@kencu mentioned he actually had libcxx built on Leopard PPC long ago, but didn’t use it much.

[iains]

Building libcxx (in a sense that compilation went through completion) for ppc wasn’t too hard, I just had to add ppc ppc64 in buildit scripts and remove a couple of flags which gcc didn’t get: https://trac.macports.org/ticket/64932

Ah maybe the problems with long double were fixed (I did pass my patches to the libc++ maintainer some time ago, perhaps they were included).

If lib++ builds and passes its test suite, then ISTM that the -stdlib= patch would work OK (but it is not clear to me that it will be a "better" solution for macOS versions that default to libstdc++ ..)

[barracuda156]

@iains

then ISTM that the -stdlib= patch would work OK

Could you refer to the patch in question, please?

[iains]

@iains

then ISTM that the -stdlib= patch would work OK

Could you refer to the patch in question, please?

It is already present in GCC-11 and on master (r11-6333-g662b9c55cf06 was the patch applied).

So, you'd have to configure your GCC build with --with-gxx-libcxx-include-dir= pointing to the libc++ headers and make some arrangement for libc++.dylib to be found at link time.

It is possible that you might need to make some adjustments to the driver options (since libc++abi would not be used by earlier macOS [<= 10.6]), but the driver would be expecting libc++abi to be installed along with libc++.

I have not tried this on powerpc-darwin9, but I have used the -stdlib= option extensively to build OSS codes on 10.7+ (it works pretty well, GCC is very compatible with libc++).

[kencu]

@iains -- I did include your nanoseconds patch a few years back in our libc++ v5.0 build (that is currently the one we use on macports):

https://github.com/macports/macports-ports/blob/master/lang/libcxx/files/2004-libcxx-includes-Fix-up-thread-constexpr-for-GCC-where-the-PPC-port-cant-do-longlong-constexpr.patch

at some future point, and after much discussion, something similar was eventually included upstream, ergo it all works nicely now on debian11 ppc.

[kencu]

And before anyone pushes to have the libc++ on macports updated to some newer version, the reason it is still at v5.0 is that works great, for years now, offers lots of features not available in MacOS until about MacOS 10.14 or so, and remains very compatible. (At a certain point software built against libc++ seems to lose compatibility with software built against older versions of libc++, so don't go looking for trouble with no good reason I figure).

I was personally considering updating that libc++ to v7.0 once llvm/clang-7.0 for PPC was fixed perhaps, as one big upgrade.

[iains]

(not that I would be pushing anything here, but) note that later versions of libc++ require C++14 or 20 depending on which - so it could be a non-trivial change indeed.

[barracuda156]

(not that I would be pushing anything here, but) note that later versions of libc++ require C++14 or 20 depending on which - so it could be a non-trivial change indeed.

@iains C++14 is supported with gcc11, isn’t it?

[kencu]

sure gcc11 supports c++14.

MacPorts plans to use gcc10-bootstrap as the bootstrap compiler to build everything that requires newer tooling eventually, so we should be very comfortable for the next few years at least.

Once we get all the kinks out of problems we're having building gcc10-bootstrap, of course. Gotta keep everyone busy and thinking :>

[barracuda156]

@kencu Yeah, our friend @catap broke it in 4th iteration and left at that :)

[barracuda156]

@kencu Yeah, our friend @catap broke it in 4th iteration and left at that :)

With recent update, it is fixed now :)

[barracuda156]

@iains Which version of LIBCXX would you recommend to try? For one thing, I could use your from llvm-7 or llvm-8 tree. But I recall you mentioned elsewhere that ppc(64) support was improved in more recent LLVM? Would it be a better pick using libcxx-11 or libcxx-14? (As @catap explained, v. 15 does not build with GCC even for Intel presently, so latest version is off question.)

[barracuda156]

UPD. Well, I am trying to build libcxx-14 on Rosetta now :)

One bug in source code discovered:

:info:build /opt/local/var/macports/build/_opt_PPCRosettaPorts_lang_libcxx/libcxx/work/build/include/c++/v1/__config:1421:74: error: 'init_priority' attribute is not supported on this platform

See: https://bugs.llvm.org/show_bug.cgi?id=38160 (so actually a bug, but easily fixed).

Now need to fix a bunch of undefined symbols in -exported_symbol[s_list]. To be updated.

[iains]

there were some changes needed to libcxx to support ppc, especially on darwin9 where there are some system math header issues. (I did pass those onto the libcxx folks, don't know what was incorporated).

llvm-14 should build OK with gcc10.4+ at least on intel - but upstream has removed more of the powerpc-darwin code from it, so don't expect anything to work.

TBH, I'd say that the llvm-711 branch version of libcxx is most likely to be most compatible with powerpc-darwin9 / rosetta.

At some stage (in the not too too distant future) I hope to have an llvm-11 version with the powerpc-darwin port restored there. This is a useful version, since it can be built with cmake-3.9.6 which means that there's a path to building it starting from only gcc-4.2 .. (build cmake 3.9.6, xtools 0.7.0, gcc-10.4, and then llvm-11) .. but, yeah some of that stuff is not yet released ;) .. just pointing out the roadmap.

[kencu]

(I did pass those onto the libcxx folks, don't know what was incorporated).

After a (too long) discussion about them that went on for several years, they were, with minor tweakage.

[kencu]

(though if @catap or me gonna try updating libcxx port in Macports, then Intel builds with clang will need to be tested too).

updating it beyond the current libcxx-5.0 version is easy....

updating it without breaking a whole bunch of stuff is hard, as it is moving target. libcxx-7.0 is pretty good, I've been using it for several years on 10.6.8. As far as I can see though, it offers nothing important that libcxx-5.0 already offers, so I never bothered updating the macports version.

updating libcxx beyond 7.0 is quite likely to cause wreckage as things really started to change after that, but it might be possible. No real benefit other than causing lots of TUMS sales, however, as libcxx-5.0 is already much newer than some of the older systems macports supports like 10.7, 10.8, and 10.9.

So that is why it was "just left" at 5.0.

I (as you have likely come to know) really dislike updating things for no good reason, especially in the toolchain, when it is already working very well. It just causes a lot of trouble.

Updates to the toolchain need to be VERY WELL TESTED. And on MacPorts, lately, that needs to be closely watched.

[barracuda156]

• the stuff is unreleased because it is not ready yet - I do not think it would help you if I push something broken :)

@iains Yes, absolutely :)

• using the libcxx headers unmodified will work for some code, but not all (because clang and GCC have some code-gen differences especially around newer C++20 features).

@catap @kencu Do you know if this has been tested within Macports, or the variant was just added? Looks like the port is borrowing includes as-is from Clang installation.

• I made a modified version of the llvm-9 ones (that is a magic version because it has support for some exceptions that GCC uses, but clang did not have in earlier cases). https://github.com/iains/llvm-project/tree/9.0.1-gcc-stdlib ... you might find this more useful than the "vanilla" ones.

@iains Did I get it right that you advise borrowing includes from this branch and using those with libcxx-7 (from your repo)?

(That may be difficult to sell to Macports, unless we make a separate port for PPC. But that is our – Macports – problem, of course.)

[kencu]

@catap @kencu Do you know if this has been tested within Macports, or the variant was just added? Looks like the port is borrowing includes as-is from Clang installation.

I saw that. I believe it is completely untested. Some things might work, nobody can say.

[barracuda156]

• I made a modified version of the llvm-9 ones (that is a magic version because it has support for some exceptions that GCC uses, but clang did not have in earlier cases). https://github.com/iains/llvm-project/tree/9.0.1-gcc-stdlib ... you might find this more useful than the "vanilla" ones.

@iains Did I get it right that you advise borrowing includes from this branch and using those with libcxx-7 (from your repo)?

(That may be difficult to sell to Macports, unless we make a separate port for PPC. But that is our – Macports – problem, of course.)

Just as an update: I actually made a port for that, which installs libcxx7 with a patch from version 9 enabling coroutine for gcc usage. On a very basic level it seems to be functional, anything further still has to be tested.

[barracuda156]

@kencu Ken, what would be the preferable way to handle LIBCXX update (I consider updating to v. 7.1 with @iains fixes)?

1. Make an update to existing libcxx port which is stuck at v. 5.
2. Make a variant to it.
3. Make a separate port for libcxx-ppc, leaving existing thing as it is.
4. Something else?

UPD. Just saw your reply above. From what I understand, libcxx-5 did not work for PPC? But in any case, I have no intention to break anything for others :) We can make a separate port for PPC systems, so it will not adversely affect anyone at all.

[kencu]

As far as I tried it, libcxx-5.0 worked OK on 10.5 PPC. It passed lots of the test suite (you can run the test suite for libcxx and libcxxabi yourself, and start to see how well it works). You can just use it right now with gcc10+, after some plan for coherent libc++ headers is sorted out.

Regarding updating it to libcxx-7.0, my plan was to wait until @iains libcxx/llvm/clang/etc -7.0 is finished and works and then consider doing an upgrade all in one swoop, once it has been properly tested.

[barracuda156]

You can just use it right now with gcc10+, after some plan for coherent libc++ headers is sorted out.

@kencu How we could sort those, practically? (I mean in such a way that it can be pushed into the master.)

Regarding updating it to libcxx-7.0, my plan was to wait until @iains libcxx/llvm/clang/etc -7.0 is finished and works and then consider doing an upgrade all in one swoop, once it has been properly tested.

Given libcxx is usable with GCC now, we may divorce these, I guess. (No one has time to fix Clang, and with insane speed of release of its versions we cannot support that anyway.)

[kencu]

You can just use it right now with gcc10+, after some plan for coherent libc++ headers is sorted out.

@kencu How we could sort those, practically? (I mean in such a way that it can be pushed into the master.)

No idea. The only one who really knows where all the potholes might be in the headers is Iain, so you just have to wait for that to become a priority for him.

Given libcxx is usable with GCC now, we may divorce these, I guess. (No one has time to fix Clang, and with insane speed of release of its versions we cannot support that anyway.)

The clang version on PowerPC will be pegged at something like version 7.0 forever, so whatever version releases clang does is irrelevant.

MacPorts will be unlikely to agree to a bunch of gcc-libcxx spaghetti junk thrown into Portfiles to support an almost-never-tested gcc-libcxx built plan that almost nobody ever uses. Good luck with that one.

Once it works properly, and the default can be moved, maybe.

clang and libcxx work great on 10.5 Intel now (have for years, since I fixed them) and they also work pretty good on 10.4 Tiger Intel -- and still years later MacPorts does not easily support either of those :>

So that gives you an idea.

[iains]

@barracuda156 answering your "what should i use" question is not so easy.

Since llvm-7 (and more so since llvm-5), C++ has changed quite a bit, so that if you want to support modern C++ features [which both GCC and clang do] (from headers and/or the compiler) then you will need a newer set of headers than llvm-5/7 libcxx.

If the features you want to support require a newer libc++.dylib than is installed on the system, you are into the "two libc++'s living together" territory and you should approach that with extreme caution and a clear head (i.e. figure out how it is going to work before it gets deployed).. We have an unfixed mess with two libstdc++ versions on earlier Darwin already, let's not make a second one.....

which libcxx headers:

I have been trying to find a way to figure out (roughly, at least) where the Xcode libcxx headers come from that correspond to each Xcode release. The plan would then be to identify a relevant set for each OS version ..

.. I suspect that the minimum version we would want to use with GCC would be from LLVM-9 (if that works) because then we have the headers for C++20 support .. plus the exception specs. It is possible to add a work-around to the llvm-7 libcxx headers to provide the exception spec that GCC needs.

So ... as with all toolchain / installed system stuff .. this needs very careful consideration .. it is not a question of "selling:" something - it's a question of making sure that it works properly by design, rather than luck ;)

[iains]

@barracuda156 I guess, the fact is that there probably is not much you can do conclusively "today" .. however, GCC + LLVM-9 headers from the repo mentioned should work on systems with libc++ installed (no need to build libc++).

@kencu on any system that already has libc++ installed (i.e. darwin11+), iff you intend to build a newer libc++, then I think it must (at minimum)
a) be built on top of the installed libc++abi library (so that the allocators are the same between the libraries) - newer llvm builds have introduced a "system-libcxxabi" source for this, and those changes might be back-portable to llvm-7.

b) the inline namespace should be bumped to something other than __1 (and that avoids the values reserved by the project).

A variant of those two factors should be a solution also to using libc++ on Darwin9 / 10 (but building on top of libstdc++ allocators)

Likewise, a similar idea is in the pipe for fixing the 'two libstdc++ issues' on Darwin 9/10.

... if days were 72 hours long... and there was no need to do $dayjob .. it would happen quicker .. but ..

[barracuda156]

A variant of those two factors should be a solution also to using libc++ on Darwin9 / 10 (but building on top of libstdc++ allocators)

@iains What Macports has in libcxx port now is building and installing both libc++abi and libc++, which was (?) apparently tested for Intel systems, at least 10.6.x, and @kencu says above it was also functional for PPC (on 10.5.x).

Does that create some sort of a problem? I do not really know how to build on top of libstdc++ allocators.

Given that 10.5–10.6 do not have native LIBCXX, we do not face a conflict issue. The only questions are which version to pick (so that it is compatible both with OS and features needed for GCC) and how to modify headers appropriately.

[kencu]

which was (?) apparently tested for Intel systems, at least 10.6.x, and @kencu says above it was also functional for PPC (on 10.5.x).

After Jeremy first set it up in 2015, I tested the hell out of the upgrades to libcxx-5.0, for months, and added thread_local to it, before I ever pushed it.

That would be why it works so well :>

[iains]

• 10.4..10.6 do not have a libc++ .. but they do have an ABI library (which is, unfortunately, part of libstdc++ so cannot be disentangled easily) .. that is accounted for in the libc++ builds, by forwarding libstdc++ as the "abi" library (which also happens to supply the libstdc++ symbols but without the inline namespace). [actually, that mechanism is used the same way on Linux systems where the system libstdc++ provides the ABI lib]. I think it can be possible to make this more transparent by adding a 'system-libstdc++' target as the ABI library (in a similar way to the system-libcxxabi case).

• does it create a problem? ... well, if sufficient testing showed no problems, I guess the answer is "theoretically, but not in practice". The issue would be an object allocated in one allocator and then destroyed in the other ..

@kencu you will find no argument from me about testing ;) .. one reason things happen slowly is because of that (and even then things slip through the cracks :/ )

[barracuda156]

@iains Resurrecting the issue since I have written a portfile to build libc++/libc++abi (from your llvm7 branch with a few extra patches) on PowerPC, rebuilt gcc12 to support stdlib flag, and it seems to be functional at least on some basic level.
At least I have been able to build unrar (easy since no extra dependencies) linking it to libc++, and it not just builds but actually works.

I have two technical questions here:

1. libc++ links to the libSystem and libgcc_s: does this present a problem to solve or is it just as it should be?
2. A patch from David Fang @fangism to support 64-bit atomics without libatomic did not work for me: build fails if it is applied. In result, libc++ gets linked to libatomic (there is no circular dependency with gcc, since I use an isolated no-dependency gcc10-bootstrap port to built this, so libatomic is from there, not regular Macports libgcc). Is this a trouble still?

P. S. If you will consider sharing your work on version 11 (or later), it would be very helpful, and now practically: we have a ready set-up to test it in practice. Just libc++/libc++abi is sufficient. I intend to have them specifically for PowerPC (to avoid a chance of breaking anything for Intel, as well for an ease to update) and to use with gcc (so no need in clang or even llvm).

[iains]

linking to libSystem and /usr/lib/libgcc_s is expected, I would think.

I am sorry not to have been able to progress much on the LLVM-11 stuff; the atomics support needs to be thought through - probably something similar to the mechanism used by AIX is likely.