10.6 Snow Leopard PowerPC Development

[barracuda156]

UPD2. Preliminary conclusion is that libdispatch is usable (not a huge surprise perhaps, since my port for it worked on 10a190), which means that related hackery can be probably dropped, and everything which relies on GCD will just build.
A tiny patch for X server still needed: I dropped it initially, thinking I get a standard 10.6.8 build like on x86, but no, that breaks the app. Patch being restored, X server works. (It is still necessary to wipe out Apple X11 and XQuartz.)

Qt and X server were the biggest concerns for software, since a lot of stuff depends on them, especially things which normal people use (video, audio, web, editors, photo etc.).

I will still need a day or two to fix some minor issues and rebuild a couple of huge ports. I will update on that later in a dedicated thread. Here this is just FYI.

P. S. @educovas This is not at all urgent, but when you have time for this, could you please confirm if we have compatible versioning of graphics-related frameworks between Nvidia-specific and ATI-specific images of 10.6.8? So that at least in principle Qt built on one will work fine on another, etc.

 

[Jazzzny]

With 10.6-API compatible AppKit/Quartz, would it be possible to restore more of the native cocoa backends for various frameworks (i.e. TCL, GTK)?

 

[barracuda156]

With 10.6-API compatible AppKit/Quartz, would it be possible to restore more of the native cocoa backends for various frameworks (i.e. TCL, GTK)?

More as compared to what? 10.5? Sure, but it is already the case with 10a190. More than what 10a190 is capable of? This may depend, of course, but clangisms won’t be supported (no arc, no blocks etc.) and at least some frameworks are not at 10.6 level (and some won’t ever be, since they never existed for PowerPC – OpenCL or Apple Java, for instance).

I do not really know to what extent 10a190 SDK differs from 10.6.8 in practical terms. The only stereotypical issue with 10a190 builds is libdispatch, but that was fixed earlier by my port (of course, not needing a special port still makes life easier).
I hope we get some random improvements generally, but that is yet to be seen. I think there are not many patches which were added specifically for 10.5 vs 10.6 SDK; if this is correct, then improvement in terms of additional software being supported will be minimal.

I expect some specific known bugs to be sorted out though (building gdb-apple, building fuse ports, some OpenJDK issues etc.).

P. S. I will see soon if there are meaningful improvements for Qt, some multimedia apps and browser. At the very minimum, perhaps we can drop some patches eventually.

 

[ChrisCharman]

Looks like we have internet, so the only factor preventing me from switching to 10.6.8 is gone.

So now the important question: are there any reasons (well, besides a slight inconvenience of manual network config) to hold to 10a190 or we can just drop it for good?

While perhaps most of software will be compatible, regardless of being built on 10a190 or 10.6.8 (and of course I will not rebuild literally all 13k ports for the new SDK), some will not – at least if built optimally for 10.6.8.
You know the OS itself far better, so I need your opinion here. If we consider 10.6.8 kinda-production-ready, then I just build everything on 10.6.8 from today and, provided everything works as expected, start dropping 10a190 hacks from defaults (I will keep those in variants, so 10a190 is still supported if needed).

P. S. I understand that you may not personally be using my PowerPC Ports (and TBH I have no idea if anyone is LOL), but at least potentially this will impact some people.

Aside from exploration of, experimentation with and for historical archival purposes which should be recorded on the other thread, I feel that using the most current version of Snow Leopard as our ‘base’ to work from makes the most sense and that 10A190 can be set aside as primarily a ‘parts bin’ or reference system for troubleshooting and comparing issues and components moving forward.

Did it work for you? See also a reply of the developer here.

@educovas @ChrisCharman @jkchr1s
On a general note: until either UPD is actually fixed in 10.6.8 or someone comes up with a solution not relying on any external components, what is a better way to have `utdns` provided to potential users of 10.6.8, which will be straightforward (i.e. with minimal manual tweaks – we do not benefit from limiting user-base, it is already tiny)?
There are a lot of software doing something to this end, i.e. DNS over TCP, but other stuff which I saw pulls in a lot of dependencies (like newer pythons and/or newer gcc), and that is undesirable in this case.
Also, while I added `utdns` to MacPorts, for the system usage it should not depend on MacPorts (or my PowerPC Ports, w/e).
P. S. I think it will be nice to have an “expected default” way of installing rather than leaving it to an end-user, since it is easier for debugging, be it needed.

As this is the only confirmed workaround, until we identify and fix the internal problem, and you state that the port has no dependencies, simply providing a link to the package installer in the wiki post under a ‘Known Issues and workarounds’ section should be good enough for now.

10.6.8 is usable but ofc course you might see problems that don't exist in 10A190 but this is my opinion. I don't know if anyone else used this OS enough to know if it's close to "kinda-production-ready" but we might see more people trying it for more than 5 minutes now that we have internet.


it's probably a good idea to add a small guide for this on the first post as the current workaround for the lack of internet connection and maybe now that 10.6.8 might me more used, we could collect bugs and workarounds like disabling sleep to reduce kernel panics and include on the first post.

I agree, ‘production ready’ is a bit overzealous but certainly with working internet there will be more incentive for others to jump in and provide further testing and feedback that we can work from.

By the way, there are no sources for Xcode itself (not Unix tools), right? So the only way to get IDE working is to pull needed components from some earlier builds where those are still universal?

Standard 3.2.6 GUI is unusable, since some required plugins lack ppc slices.

If someone happened to already track some components (which Xcode had the latest universal ones), it would be helpful to know. Only relevant for the stuff which we cannot rebuild from source, of course.

No, unfortunately the IDE itself is proprietary and only the developer tools sources are available. We will have to go through all the beta versions as we did back with 10A190/10A222 etc to identify most recent working app components if an updated IDE is desirable. It’s worth noting that Xcodebuild is useable from the command line without launching Xcode IDE itself however.

 

[Jazzzny]

From what I can remember, 3.2.6 works alright and can compile on 10.6.8. However, Xcodebuild is Intel-only and does not work at all, at least with its stock binary.

 

[barracuda156]

Aside from exploration of, experimentation with and for historical archival purposes which should be recorded on the other thread, I feel that using the most current version of Snow Leopard as our ‘base’ to work from makes the most sense and that 10A190 can be set aside as primarily a ‘parts bin’ or reference system for troubleshooting and comparing issues and components moving forward.



As this is the only confirmed workaround, until we identify and fix the internal problem, and you state that the port has no dependencies, simply providing a link to the package installer in the wiki post under a ‘Known Issues and workarounds’ section should be good enough for now.



I agree, ‘production ready’ is a bit overzealous but certainly with working internet there will be more incentive for others to jump in and provide further testing and feedback that we can work from.



No, unfortunately the IDE itself is proprietary and only the developer tools sources are available. We will have to go through all the beta versions as we did back with 10A190/10A222 etc to identify most recent working app components if an updated IDE is desirable. It’s worth noting that Xcodebuild is useable from the command line without launching Xcode IDE itself however.

I do not care much about being able to use Xcode from its GUI, since that’s not how it is used from ports, however it is certainly insufficient just to replace a few Unix tools. A lot of things will build just after doing that, but a lot of things actually using Xcode stuff will be broken. Even with Unix tools, I had to replace substantially more than as, ar, ld and gnumake when I used newer Xcode versions on 10a190.

So yeah, I think it is desirable and to certain extent required.

It will be very helpful to have Unix tools properly sorted too, since there are more Intel-only binaries which have to be rebuilt or in the worst case replaced.

 

[barracuda156]

Though priority are Unix tools, of course. For stuff using Xcode (with xibs etc.) a workable option is to compile in Rosetta: presumably now this gonna work correctly, since we have mostly 10.6.8. (It did not work well for 10a190, at least not without manual tweaks, since while apps could be compiled for ppc, linking was incorrect for what 10a190 expects, so apps just didn’t launch with complaints from dyld.)
There are not too many apps of this kind which I’m interested in (or even in principle) that are compatible with any 10.6, so I can do that manually on in x86 VM and then borrow apps in question into 10.6.8 ppc, which in turn makes those available pre-built.

 

[ChrisCharman]

I do not care much about being able to use Xcode from its GUI, since that’s not how it is used from ports, however it is certainly insufficient just to replace a few Unix tools. A lot of things will build just after doing that, but a lot of things actually using Xcode stuff will be broken. Even with Unix tools, I had to replace substantially more than as, ar, ld and gnumake when I used newer Xcode versions on 10a190.

So yeah, I think it is desirable and to certain extent required.

It will be very helpful to have Unix tools properly sorted too, since there are more Intel-only binaries which have to be rebuilt or in the worst case replaced.

Though priority are Unix tools, of course. For stuff using Xcode (with xibs etc.) a workable option is to compile in Rosetta: presumably now this gonna work correctly, since we have mostly 10.6.8. (It did not work well for 10a190, at least not without manual tweaks, since while apps could be compiled for ppc, linking was incorrect for what 10a190 expects, so apps just didn’t launch with complaints from dyld.)
There are not too many apps of this kind which I’m interested in (or even in principle) that are compatible with any 10.6, so I can do that manually on in x86 VM and then borrow apps in question into 10.6.8 ppc, which in turn makes those available pre-built.

I haven’t played around enough with 3.2.6 on 10.6.8 yet to offer anything unknown. Most of what i’ve built over the years has been done using 3.2 (mainly on 10A190 and 10A222) with rebuilt toolchain and where necessary, Xcode on an intel 10.6.8 machine targeting powerpc for cross-compilation.

Building using rosetta is non-standard and not something that seems necessary if running intel Snow Leopard as its Xcode (3.2.x versions) support PowerPC as a target already. Rosetta also uses its own version of libsystem so there may be peculiarities there.

What you require for MacPorts integration with Xcode however is not something i’m particularly knowledgeable about as that’s been your area of expertise.

 

[barracuda156]

From what I can remember, 3.2.6 works alright and can compile on 10.6.8. However, Xcodebuild is Intel-only and does not work at all, at least with its stock binary.

I asked in the old thread, but this really belongs here: if you already rebuilt other Unix tools, it would be very helpful to have those. Besides as, ld and gnumake there are a number of other essential ones which are Intel-only in 3.2.6 (ar, libtool, m4, nm for example).

 

[Jazzzny]

I'll try to get a full 3.2.6 command line tool environment compiled in the next few weeks, it would definitely be very nice to have a "full 10.6.8 developer environment" to essentially match Rosetta.

 

[barracuda156]

A bit on a side note: does anyone know if this error is just because our iTunes is too old (and we cannot do anything then), because of version mismatch due to sourcing of something related from 10.5.8 or it is something tweakable in the build?

This is the same version of LastFM scrobbler which I tried elsewhere, and on 10.8 and 10.15 it worked normally (no previews, but scrobbling worked). I do not know if it works on 10a190, since there iTunes is broken.

P. S. For some reason, no display of unicode fonts, not sure if Qt or macOS at fault.

 

[barracuda156]

Building using rosetta is non-standard and not something that seems necessary if running intel Snow Leopard as its Xcode (3.2.x versions) support PowerPC as a target already. Rosetta also uses its own version of libsystem so there may be peculiarities there.

Yeah, this is what I meant re building, it just became habitual to refer to Rosetta because non-Apple gcc does not support multiple arch flags, and MacPorts does not really have facilities for cross-compiling. Xcode can just cross-compile, of course.
P. S. I did not know Rosetta uses some alternative `libsystem`. Does it?

 

[Jazzzny]

It does not, it simply needs to load the ppc slice of the standard libsystem found in /usr/lib.

 

[ChrisCharman]

It does not, it simply needs to load the ppc slice of the standard libsystem found in /usr/lib.

My mistake. I must have remembered incorrectly from when i was playing around with the shims etc contained within oah a few years back. Thanks for the clarification @Jazzzny.

 

[educovas]

P. S. @educovas This is not at all urgent, but when you have time for this, could you please confirm if we have compatible versioning of graphics-related frameworks between Nvidia-specific and ATI-specific images of 10.6.8? So that at least in principle Qt built on one will work fine on another, etc.

the image using OpenGL from 10A190 should be safe since it did not require any shims but the image with OpenGL and other frameworks from 10.5.8 requires the wrappers to be rebuilt with the correct version and I'll do that eventually.

 

[barracuda156]

the image using OpenGL from 10A190 should be safe since it did not require any shims but the image with OpenGL and other frameworks from 10.5.8 requires the wrappers to be rebuilt with the correct version and I'll do that eventually.

Got it, thank you. This will allow me to build stuff on the Quad without worrying then, but whatever uses OpenGL may not be usable for anyone on an ATI image.
(Once you get time to deal with ATI image fix, I will test software for it on my end, as I can put ATI card into the second PowerMac. We hopefully won’t have a lot of stuff in need of cross-testing, but at least QMPlay2 I wanna have in production-ready condition, both for myself and for others, since it is the best option for multimedia and YouTube.)

 

[educovas]

Got it, thank you. This will allow me to build stuff on the Quad without worrying then, but whatever uses OpenGL may not be usable for anyone on an ATI image.
(Once you get time to deal with ATI image fix, I will test software for it on my end, as I can put ATI card into the second PowerMac. We hopefully won’t have a lot of stuff in need of cross-testing, but at least QMPlay2 I wanna have in production-ready condition, both for myself and for others, since it is the best option for multimedia and YouTube.)

Just reminding that the image with OpenGL from 10.5.8 is not for ATI only, Nvidia also works with that.

 

[ChrisCharman]

From what I can remember, 3.2.6 works alright and can compile on 10.6.8. However, Xcodebuild is Intel-only and does not work at all, at least with its stock binary.

The XcodeBuild binary appears to be universal, at least on the 3.2.6 with iPhone SDK package installer that i have - many of the other included apps and binaries, particularly those installed to /usr are intel only however and need to be replaced (rebuilt from source as was done for 10A190) but the intel apps will need to be pulled from earlier versions of Xcode, such as PackageMaker etc.

 

[barracuda156]

Does anyone know what causes these warning and error?

2024-12-22 08:27:07.155 xcodebuild[23962:80b] CFPreferences: user home directory at file://localhost/opt/local/var/macports/home/ is unavailable. User domains will be volatile.

2024-12-22 08:27:08.680 xcodebuild[23962:80b] _XCDistributedBuildHostInfoTask encountered an error: Error Domain=NSPOSIXErrorDomain Code=86 UserInfo=0x73bd3d0 "The operation couldn’t be completed. Bad CPU type in executable"

They are probably independent, since the first one I keep seeing on 10.6.8 with non-Xcode builds as well, while the second is Xcode-specific, and I have seen it on 10a190 with Xcode from 10a222 as well, but not sure which exactly binary causes it. It is not xcodebuild itself, of course.

 

[Jazzzny]

A happens on 10.6.8 Intel as well, B is probably caused by some binary missing its ppc slice.

 

[barracuda156]

A happens on 10.6.8 Intel as well, B is probably caused by some binary missing its ppc slice.

Interesting re A. I don’t recall seeing it earlier, but I usually used 10.6.8 in a VM (not sure if consequential here) and did not build much from source on it. Intel is i386, x86_64 or both?

Re B, yes, it is clearly the case, I just wanna know what to replace to get rid of it. Xcode got a lot of binaries and plugins scattered across multiple directories.

 

[Jazzzny]

Interesting re A. I don’t recall seeing it earlier, but I usually used 10.6.8 in a VM (not sure if consequential here) and did not build much from source on it. Intel is i386, x86_64 or both?

x86_64, I believe I saw it when compiling the fish shell.

 

[ChrisCharman]

Possibly distcc but that’s only a guess, i agree with @Jazzzny and the solution is more than likely to recompile whichever binary tool is causing the problem. Sometimes building 32 bit (i386) and 64 bit (x86_64) must be done separately as well in certain instances and then lipo’d together if needed.

 

[barracuda156]

Possibly distcc but that’s only a guess, i agree with @Jazzzny and the solution is more than likely to recompile whichever binary tool is causing the problem. Sometimes building 32 bit (i386) and 64 bit (x86_64) must be done separately as well in certain instances and then lipo’d together if needed.

To make life easier, I just build for ppc, without other archs. distcc was my guess, but after replacing both distcc in /Developer/usr/bin and /usr/bin I saw no change.

 

[barracuda156]

@ChrisCharman @educovas @Jazzzny Could someone remind me what was broken about Darwinbuild that we kinda agreed it is actually broken (last time it was discussed in another thread)?
On 10a190 it does not build out of the box, but a fix is trivial, it seems.