libcxx for PowerPC

[barracuda156]

I have built libcxx for PowerPC now. All it took is remove three flags which gcc does not support and changing archs in lib/buildit. However I need to check somehow if it is usable after all.

gcc11 complained about 2 flags: -Wshorten-64-to-32 and -Wnewline-eof. gcc7 in addition didn't like -Wmismatched-tags. Then obviously for both buildit I changed:

-      RC_CFLAGS="-arch i386 -arch x86_64"
+      RC_CFLAGS="-arch ppc -arch ppc64"

A couple of problems:

1. Despite building on 10.5.8 and 10.6, dylib got placed into /opt/local/var/system_roots as an archive. From what I understand this should happen on 10.7+.
2. While on Leopard I asked for +universal, unpacked dylib is ppc32-only:

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

Port claims to be universal though:

36-109:libcxx svacchanda$ port -v installed libcxx
The following ports are currently installed:
  libcxx @5.0.1_4+universal (active) requested_variants='+universal' platform='darwin 9' archs='ppc ppc64' date='2022-04-03T15:30:57+0800'

During compilation gcc complained about archs:

g++-mp-7: warning: ppc64 conflicts with ppc (arch flags ignored)

Which is perhaps the cause of the problem. (Maybe missing muniversal 1.0 in Portfile is to blame.)

How can I check if resulting dylib is practically usable?

[catap (Kirill A. Korinsky)]

Hey, to be honest I really doubt that libcxx can be used without clang.

[barracuda156]

Replying to catap:

Hey, to be honest I really doubt that libcxx can be used without clang.

Let’s fix things one at a time :)

[kencu (Ken)]

As I mentioned before, I built libcxx on PowerPC in about 2018. It was a branch in the LeopardPorts repo. I didn't try to enable it in MacPorts for the usual 1000 reasons we keep talking about, though (it was not useful, and will just lead to 1000 pointless tickets).

Run the test suite, and see how it does.

It is linked against parts of libgcc, which is not perfect, and that needs to be taken into account.

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).

The only way I was going to enable libcxx on PowerPC for MacPOrts was:

1. if it actually worked well
2. if there was some actual need for it (ie a PowerPC system that would be installed against libc++, as we do on 10.6+).

As #2 was not going to happen until we had a clang-7.0+ that actually worked on PowerPC, which we don't have, there was no point to it.

[kencu (Ken)]

All this stuff -- llvm on PowerPC, clang on PowerPC, libtapi on PowerPC, libcxx on PowerPC, newer ld64 on PowerPC, etc -- all of it -- depends on Iain finishing llvm/clang for PowerPC to actually work.

Once that works, the rest of the dominoes can fall quite easily.

BUT -- I waited 5 years for that to happen, and it never did. It might happen one day. It might not. We have clang-9 and libc++-9 on Intel Leopard for some years now, I fixed that much -- but we rarely use it, and MacPorts still defaults to libstdc++ on those systems anyway.

So I moved on -- debian-11 on PowerPC works just great with llvm-14, clang-14, libc++-14, gcc-11, rust, etc, etc, etc.

And debian11 builds and runs all this current software like qt5.15, etc, which Darwin PowerPC never ever will do.

So, ...

[barracuda156]

Replying to kencu:

And debian11 builds and runs all this current software like qt5.15, etc, which Darwin PowerPC never ever will do.

This is off-topic, but I was wondering, what exactly prevents Qt5 from building on Darwin PPC (given it builds on Linux PPC, as you notice)?

[kencu (Ken)]

I want to be clear that I do enjoy seeing you work on this, and I get your enthusiasm. I don't want to dissuade that at all! The whole reason that I posted how to enable MacPorts on that 10.6-for-PPC user forum in the first place was to let folks like you know that MacPorts would be useful for you!

Having libc++ build on PowerPC might be useful now that gcc11 can use it. You never know.

But what we (you) really need to do is find a small group of people who are interested in PowerPC and who can take Iain's work on llvm-7/clang-7 on PowerPC and finish it.

He has posted that he has actually finished it to a point where the lowering works on Darwin now. That was not too long ago (past few months). But he said it was too rough for him to make it public.

Someone with time might finish that!

[barracuda156]

Replying to kencu:

I want to be clear that I do enjoy seeing you work on this, and I get your enthusiasm. I don't want to dissuade that at all! The whole reason that I posted how to enable MacPorts on that 10.6-for-PPC user forum in the first place was to let folks like you know that MacPorts would be useful for you!

Thank you! In fact it was your participation there that made me motivated to work on that.

Having libc++ build on PowerPC might be useful now that gcc11 can use it. You never know.

If gcc11 may be able to use it, that’s interesting. I will look for the relevant info.

But what we (you) really need to do is find a small group of people who are interested in PowerPC and who can take Iain's work on llvm-7/clang-7 on PowerPC and finish it. He has posted that he has actually finished it to a point where the lowering works on Darwin now. That was not too long ago (past few months). But he said it was too rough for him to make it public.

Well, hopefully he makes in public eventually, as having something working will be a great start. I recall he said it may make sense to use later clang as ppc64 was implemented in it (unless I misunderstood smth).

[barracuda156]

Replying to kencu:

As I mentioned before, I built libcxx on PowerPC in about 2018. It was a branch in the LeopardPorts repo.

I know you had clang-5.0 on PowerPC. I tried to build it just to see how it goes, but it asked for libomp. Did you have it for PowerPC back then too? Or you somehow avoided this dependency?

I have WIP on libomp for PPC, but it still fails with a number of undefined symbols: ​https://github.com/iains/darwin-toolchains-start-here/discussions/30

[kencu (Ken)]

Just remove libomp from the clang-5 deps. It is completely unnecessary for clang-5 to work, and mostly unused in macports anyway, other than a very very small number of ports that (for the most part) use it optionally.

Just to go this line, and delete the libomp reference:

​https://github.com/macports/macports-ports/blob/1fcbc9a965b637c4f0d8e43268e127064531a037/lang/llvm-5.0/Portfile#L50

and presto! Your libomp troubles are over.

[kencu (Ken)]

Replying to barracuda156:

This is off-topic, but I was wondering, what exactly prevents Qt5 from building on Darwin PPC (given it builds on Linux PPC, as you notice)?

On MacOS, the qt team has decided, rightfully, to have as modern a GUI implementation as possible. Marketing, etc. If they don't do that, someone else will come along and scoop all their hard-won users. So, to have as modern a GUI as possible, they track the latest MacOS offerings, using the latest (usually) MacOS SDK and feature set.

They follow what Apple follows, which is support for the last three systems, for the most part. Everything else is dumped. We can sometimes make the newer qt versions work on older systems with some effort that upstream is unwilling to do as -- why would they?

So, qt5 won't build on darwin PPC. Now I did get qt5.4 to build on 10.6, with moderate efforts, but it was not overly useful because by the time I did that, not much software would still build against qt5.4 anyway. But some did.

To allow qt5 (and qt6) to build on older MacOS versions, you'd have to use the unix pathways, like sdl2 or gtk3 or something like that. In fact, gtk3 runs pretty good on old Darwin systems, so that could work.

However, the upstream qt code does not support building at gtk3 on Apple systems directly, and sprinkled in 1000 places throughout the qt5 and qt6 code are #ifdef __APPLE___ blocks that then take you into MacOS SDK sections.

You would have to find a way to change all of these in some what to use the APPLE sections when needed but not when not needed.

Oh, it's 100% possible to do it. A team of five or six people, who know what they are doing, working for six months to a year, could do it. That is about $1.5 to $2 million in the current salary environment. And then it is unmaintainable, as you'd need to track upstream and keep that ball rolling.

For smaller things, like FireFox on PPC, Cameron actually did do that as a "labour-of-love" for a few years, ergo TenFourFox. And I made that work on 10.4 Intel and up, with Riccardo, for the same reason. But then the codebase there flipped and it became too much work. So it was abandoned.

Which is exactly what will happen, probably, if anyone puts in the effort to make qt5.15 build as gtk3 on older darwin systems. Once everything requires qt6 (soon enough) that effort is wasted.

In addition to the SDK issues, there is a certain amount of assembly here and there in the qt code -- I haven't looked lately at just how much, but this was an issue at one point. That would also have to be translated into darwin PPC assembly. There are very few people who can do that any longer, as it is a dead skill.

So -- realistically -- there will never be qt5.15 or qt6 on darwin PPC, save a superhuman effort from someone or some group of very bored geniuses.

[kencu (Ken)]

Replying to barracuda156:

Replying to kencu:

As I mentioned before, I built libcxx on PowerPC in about 2018. It was a branch in the LeopardPorts repo.

I know you had clang-5.0 on PowerPC.

libcxx on PowerPC too.

[barracuda156]

Replying to kencu:

Thank you very much, this is very detailed. Greatly appreciated.

[barracuda156]

Replying to kencu:

As I mentioned before, I built libcxx on PowerPC in about 2018. It was a branch in the LeopardPorts repo. I didn't try to enable it in MacPorts for the usual 1000 reasons we keep talking about, though (it was not useful, and will just lead to 1000 pointless tickets).

Just in case, have you tried using Apple’s own libc++ on 10.6 PPC? I just realised it is there in /usr/lib. I know you advised to configure Macports on it with libstdc++, but not sure if that is an outcome of a test & failure with libc++ or an assumption – reasonable one, no doubt – based on architecture and/or status of DP?

[kencu (Ken)]

I would be surprised if 10.6-for-PPC came with a copy of libc++.dylib and libc++abi.dylib from Apple. I didn't look or notice.

Up to 10.6.8 from Apple did not come with any such library, for the releases, on Intel.

I advised to use libstdc++ on 10.6-for-PPC because the available gcc versions at the time (up to gcc7) could not support libc++ under any reasonable attempt at making it easy (there is a way, of course...) , gcc-4.2 would not support it, no version of clang would support it (properly) and libc++ on all PPC systems is terribly untested.

[barracuda156]

Replying to kencu:

I would be surprised if 10.6-for-PPC came with a copy of libc++.dylib and libc++abi.dylib from Apple. I didn't look or notice.

Up to 10.6.8 from Apple did not come with any such library, for the releases, on Intel.

I advised to use libstdc++ on 10.6-for-PPC because the available gcc versions at the time (up to gcc7) could not support libc++ under any reasonable attempt at making it easy (there is a way, of course...) , gcc-4.2 would not support it, no version of clang would support it (properly) and libc++ on all PPC systems is terribly untested.

I have to apologize for unwillingly giving inaccurate info. It is Macports which installed libcxx into /usr/lib, which I did not expect to have taken place. So when I accidentally noticed it there, I assumed it is a part of the OS. Indeed, the SDK has no such dylib: ​https://github.com/barracuda156/10A190/tree/main/MacOSX10.6.sdk/usr/lib I checked file info now, and the creation date is exactly when I have built libcxx port.

(Thank you for the explanation, it makes perfect sense.)

[barracuda156]

Replying to kencu:

Ken, would you be interested to try this on Leopard? ​https://github.com/macports/macports-ports/pull/21391