Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
IIRC back in my Mac OS X Server sysadmin days, there was bug in earlier 10.6.0-10.6.4(?) builds of OS X server where DNS lookups would just stop working. I remember having a ticket in with engineering at Apple because Open Directory looked itself up constantly behind the scenes, often breaking Kerberos for clients and corrupting Open Directory user accounts.
At the time, one of the workarounds was to run bind locally on the server to let it cache the DNS lookups, then use 127.0.0.1 as the name server for OS X Server.
For clients (we did this for a while for testing), you could compile and run dnsmasq (https://thekelleys.org.uk/dnsmasq/doc.html) locally. It's been several years, but I think we would run dnsmasq and point the system's DNS server to 127.0.0.1. This worked around the flaky DNS implementation on the early 10.6 builds.
I dug up an old thread mentioning what I recall doing: https://apple.stackexchange.com/questions/26616/dns-not-resolving-on-mac-os-x
I also recall (I think in 10.6) that when DNS lookups broke, using scutil was usually the command that you could play around with to get it intermittenty work.
I don't have a system readily available to test this with, but hopefully this info is worth a shot!
---
TLDR: There was a bug in early 10.6 GM releases related to DNS. What if you run a third party DNS server (dnsmasq) and point the system's DNS server to 127.0.01? Using a third party DNS server might work around the issues you're having making DNS queries, and pointing the system name server to 127.0.0.1 wouldn't require the DNS lookups to make an external request.
At the time, one of the workarounds was to run bind locally on the server to let it cache the DNS lookups, then use 127.0.0.1 as the name server for OS X Server.
For clients (we did this for a while for testing), you could compile and run dnsmasq (https://thekelleys.org.uk/dnsmasq/doc.html) locally. It's been several years, but I think we would run dnsmasq and point the system's DNS server to 127.0.0.1. This worked around the flaky DNS implementation on the early 10.6 builds.
I dug up an old thread mentioning what I recall doing: https://apple.stackexchange.com/questions/26616/dns-not-resolving-on-mac-os-x
I also recall (I think in 10.6) that when DNS lookups broke, using scutil was usually the command that you could play around with to get it intermittenty work.
I don't have a system readily available to test this with, but hopefully this info is worth a shot!
---
TLDR: There was a bug in early 10.6 GM releases related to DNS. What if you run a third party DNS server (dnsmasq) and point the system's DNS server to 127.0.01? Using a third party DNS server might work around the issues you're having making DNS queries, and pointing the system name server to 127.0.0.1 wouldn't require the DNS lookups to make an external request.
Last edited:
If you will build other ones, please upload. There are more binaries which lack ppc slices in 3.2.6, and that shows up. (Pulling over from 10a190 works, but is suboptimal, understandably.)
At least several of these compile normally via Darwinbuild.
After doing a lot of following these threads and internet searches I have 10.6.8 running on my iMac PowerMac6,3. 2GB Ram 1.25 GHZ. It's running on a firewire drive so I can boot that or 10.5 on the internal SSD. I got a working port building toolchain on 10.5 which enabled building a caching dns to overcome some of the networking issues. I just then copied all of /opt to the 10.6.8 drive. I was stumped for a long time with it still not working after building a caching DNS (I used dnscache from djbdns). I could watch the packets going and supposedly returning to the iMac but for some reason the iMac was just not seeing them. Trying what seems like a dozen or two things to sort it out, I found that the network would work reliably in 10.6.8 ONLY in 10mb mode. Full duplex. It works fine on 100mb on 10.5. Odd.
At any rate I'm trying to update the build tools and then update the 10.5 ports to 10.6.8 which will take at least a week with my speed and installed ports.
I'm running into the common issue of the finder not reflecting local or network drive ejects unless restarted.
Also I can't seem to do anything to get smb mounts working. NFS actually works ok (after a 1 minute or so hesitation). This is to a debian bookworm linux box. SMB simply won't work even though I figured out the server side changes to get it to work on 10.5. When I do it from the command line I get a "failed to load the smb library" message. Moving forward I hope to get xcode 3.2 installed so I can rebuild the macports from 10.5.
At this point testing user stuff. The DVD player works fine. Video is fine. TenFourFox works well. iTunes rips and tags CD tracks.
At any rate I'm trying to update the build tools and then update the 10.5 ports to 10.6.8 which will take at least a week with my speed and installed ports.
I'm running into the common issue of the finder not reflecting local or network drive ejects unless restarted.
Also I can't seem to do anything to get smb mounts working. NFS actually works ok (after a 1 minute or so hesitation). This is to a debian bookworm linux box. SMB simply won't work even though I figured out the server side changes to get it to work on 10.5. When I do it from the command line I get a "failed to load the smb library" message. Moving forward I hope to get xcode 3.2 installed so I can rebuild the macports from 10.5.
At this point testing user stuff. The DVD player works fine. Video is fine. TenFourFox works well. iTunes rips and tags CD tracks.
If you are okay with installing pre-built ports, I probably have everything for you (gcc14, latest cmake and few thousands of other ports).
For internet use utdns. Borrow the binary from 10.6.8 thread, from my archive on macos-powerpc.org/packages or build yourself from upstream GH. That is known to work perfectly fine, I have internet on 10.6.8 now.
You will be better off not building on 10.5 (or even on 10a190). There were changes to libSystem, and everything links differently on 10.6.8. It will likely work better to build on an Intel machine with 10.6.8 Rosetta if building natively takes forever.
As things stand, you will need a bit of manual tweaks to the set-up (largely due to Xcode), but I can write a step-by-step outline.
Last edited:
I installed the MacPorts from your signature. I assume that will download the pre-built ports if I can get it to work. I'm getting an error about Xcode not being installed. It's still the 3.1 version from 10.5 (which does run). I saw a reference to a 3.2 version from the 10a190 iso, is that what I need? I'll need to scroll through to find it.
Do you have any pointers about the SMB issue or the weird need to use 10MB on my ethernet?
Thanks a bunch!
Wipe out 3.1.4, that should not be used (someone gave that recommendation for 10a190, and it unfortunately kept floating around).
I think 3.2 from 10a190 will work perfectly fine, at least for your purposes now.
Alternatively, install 3.2.6 and replace a few binaries in /usr/bin and /Developer/usr/bin (this is a bit of a mess at the moment in a sense that we do not have a single archive or pkg for that but everything is here and there). A quick and easy way would be to borrow from 10a190 (`cp -p ` from there). A better way would be to use rebuilt from source stuff.
Once I am back to the machine (one hour or so) I will try to sort this a bit and have links available.
My PPCPorts (MacPorts for 10.6 ppc) from the site will point to an outdated path, I think. I will update it today, or just edit archive.conf and sources.conf – stuff is at macos-powerpc.org/PPCPorts now.
For smb, no idea since I do not use it, but maybe try samba3 or samba4? Both build fine at least.
Thanks, I'm fine with using the 10a190 xcode 3.2 if I find it, the links to that and the updated MacPorts rsync url will really help.
I'm going to take a few hours to sleep. It's 2am here
@atester2001 In fact you probably don’t even need a working Xcode, as long as you use pre-built stuff.
MacPorts will default to its own toolchain, unless that is explicitly overridden in a portfile.
Set macports.conf to never build from source or force installing a pre-built stuff on command line with `port install -b`.
MacPorts will default to its own toolchain, unless that is explicitly overridden in a portfile.
Set macports.conf to never build from source or force installing a pre-built stuff on command line with `port install -b`.
Thanks, I'm fine with using the 10a190 xcode 3.2 if I find it, the links to that and the updated MacPorts rsync url will really help.
I'm going to take a few hours to sleep. It's 2am here
Ok cool. By the time you wake everything should be ready, hopefully.
P. S. Image of 10a190 is linked to in the Wikipost here and available on macintoshgarden and perhaps on archive.org too. You need a DVD image, not a pre-installed dmg for this.
I got the Xcode installed, port no longer complains about that but there is something wrong in my setup using your URL. It can't find the binaries. For example:
sudo port -bv install utdns
Password:
Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'.
Error: Failed to archivefetch utdns: Binary-only mode requested with no usable archive sites configured
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_macos-powerpc.org_macos-powerpc_PPCPorts_ports_net_utdns/utdns/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port utdns failed
Does archives.conf have the correct site? http://macos-powerpc.org/packages
Also, could you say which version of MacPorts you installed? I mean which pkg, there were several.
P. S. If you don’t mind, let’s move discussion here: https://forums.macrumors.com/thread...lt-ports-unofficial-testing-welcomed.2433458/
Otherwise some ppl here get upset about anything not immediately related to the OS itself.
Last edited:
@ChrisCharman @Jazzzny @educovas Do we have a source for pkgbuild somewhere? Turned out it is Intel-only in our image. And 10a190 does not have it at all (?).
UPD. The question still stands, but if anyone bumps into the problem that MacPorts/PPCPorts cannot make a pkg because of that, just delete /usr/bin/pkgbuild, and it will fall back to PackageMaker. (Also need the same for productbuild and set package.flat no).
UPD. The question still stands, but if anyone bumps into the problem that MacPorts/PPCPorts cannot make a pkg because of that, just delete /usr/bin/pkgbuild, and it will fall back to PackageMaker. (Also need the same for productbuild and set package.flat no).
Last edited:
@barracuda156 pkgbuild was introduced with release 3.2 XCode so if sources exist they will be in that tree. Failing that, possibly 10A222 onwards worth checking. Will check my files when home later and report back on the development thread.
From comments to MacPorts code it follows that pkgbuild and productbuild are needed to build “flat” packages. So we can live without those (fixing it in MacPorts amounts to changing a fallback threshold), but it will likely pop up again elsewhere. So would be nice to have fixed.
I just noticed that Apple ld both in 3.2.6 and 4.2 links to `libLTO`, while our ld here does not:
Xcode 3.2.6
Code:
macmini:~ svacchanda$ /usr/bin/ld -v
@(#)PROGRAM:ld PROJECT:ld64-97.17
llvm version 2.9svn, from Apple Clang 1.7 (build 77)
macmini:~ svacchanda$ otool -L /usr/bin/ld
/usr/bin/ld (architecture x86_64):
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
@executable_path/../lib/libLTO.dylib (compatibility version 1.0.0, current version 3070.0.0)
/usr/bin/ld (architecture i386):
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
@executable_path/../lib/libLTO.dylib (compatibility version 1.0.0, current version 3070.0.0)Xcode 4.2 (Snow Leopard version):
Code:
10:~ svacchanda$ /usr/bin/ld -v
@(#)PROGRAM:ld PROJECT:ld64-127.2
llvm version 3.0svn, from Apple Clang 3.0 (build 211.10.1)
10:~ svacchanda$ otool -L /usr/bin/ld
/usr/bin/ld:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
@executable_path/../lib/libLTO.dylib (compatibility version 1.0.0, current version 3211.9.0)(BTW, how come version of libSystem downgraded?)
ld from the archive attached here:
Code:
macmini:macports-ports svacchanda$ otool -L /Users/svacchanda/Downloads/other\ tools/ld
/Users/svacchanda/Downloads/other tools/ld:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
I had to force disable LTO, as I couldn't find the LLVM headers at the time.
I am not even sure LTO does anything meaningful in those versions.
After doing a bunch of testing and porting on my G4 iMac PowerMac6,3, it mostly works fine for me after adding utdns with the following issues (some of which seem well known).
1) Network browse through the finder or mounting command line afp, smb or nfs doesn't work at all. All work fine on the same machine in 10.5.8
2) The known issue with un-mounting USB devices not reflected in the finder.
3) Logout goes to a black screen which freezes the computer (keyboard caps lock key light does nothing).
1) Network browse through the finder or mounting command line afp, smb or nfs doesn't work at all. All work fine on the same machine in 10.5.8
2) The known issue with un-mounting USB devices not reflected in the finder.
3) Logout goes to a black screen which freezes the computer (keyboard caps lock key light does nothing).
Ah, logout does not seem to work indeed, though for me it sends the machine into a reboot.
P. S. This is mostly 10a190 thread, better mention you talk about 10.6.8.