Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

mac57mac57

macrumors 6502
Original poster
Aug 2, 2024
272
135
Myrtle Beach, SC
GIMP 2.10 Fails to Build on 10.5.9 Sorbet Leopard

I have a new one here... I am attempting to install the MacPort of GIMP (2.10) onto my Sorbet Leopard system. The infamous "poppler" shows up as a dependency, and of course the build fails on it. In the past, I have been able to edit the port file for the app I am building, find poppler as a dependency and delete that line.

This time however, poppler is not listed as a dependency in GIMP's port file, so I am guessing that it is a dependency of one of the dependencies. I manually went through each one, but could find no mention of poppler in any of them.

Is there a direct way to figure out where the poppler dependency is coming in and kill it?

Thanks!
 
An update here. Gimp simply isn't going to build on 10.5.9.

I fought my way through all the poppler dependencies by building each gimp dependency one-by-one and eliminating poppler wherever it popped up, but in the end, gimp will not build on 10.5.9. Like several other ports, it wants a version of gcc that is not installed.

So, I will return to Gimp 2.6.8 for which I have a DMG. IT doesn't run right now either; I have borked my X11 set up again, but I will get that fixed. Too bad though... I was hoping to be able to use GIMP 2.10.x.
 
There may be hope. I arrived at the same place, with no GIMP available at all. I couldn't get GIMP 2.10 to build under MacPorts, and GIMP 2.6.11, for which I have a DMG, and which had always worked with Apple's X11, wouldn't work either. So, no GIMP at all!

In an attempt to fix this, I uninstalled Apple's X11 (which I had gotten from the Leopard install DVD) and replaced it with XQuartz-2.6.3, which I believe is the last one for Leopard and PPC. Happily, that "solved" it!

GIMP-2.6.11 and XQuartz-2.6.3 get along just fine... GIMP came up and ran AND I still have the MacPorts xorg-server-legacy as well, and so can run either X11, depending on whether I want GIMP (XQuartz) or the MacPorts I have built that depend on X (xorg-server-legacy). You may wish to try the same thing...

There is a small "silver lining" in this cloud as well... I have discovered through trial and error that Abiword 3.0.5 echos at a much faster rate under xorg-server-legacy than it does under XQuartz. There is a significantly slower response per typed key under XQuartz than under xorg-server-legacy. Under xorg-server-legacy, Abiword is *almost* usable. Echoing is still slower than I would like, but is just about the speed of mid rate typing, so that makes it useable in a pinch.

In the meantime however, and per my earlier post, I am staying with Bean until some sort of a fix for Abiword 3.0.5's typing echo rate is made available. It is too bad - I have been trying to get Abiword 3.x running for a year or more. Now I finally have it and ... and it is unusable! Murphy's Law I suppose! :)
 
  • Like
Reactions: saxfun
GIMP 2.10 Fails to Build on 10.5.9 Sorbet Leopard

I have a new one here... I am attempting to install the MacPort of GIMP (2.10) onto my Sorbet Leopard system. The infamous "poppler" shows up as a dependency, and of course the build fails on it. In the past, I have been able to edit the port file for the app I am building, find poppler as a dependency and delete that line.

This time however, poppler is not listed as a dependency in GIMP's port file, so I am guessing that it is a dependency of one of the dependencies. I manually went through each one, but could find no mention of poppler in any of them.

Is there a direct way to figure out where the poppler dependency is coming in and kill it?

Thanks!

Throwing out random dependencies in a hope something gonna work is not generally a correct approach. In some cases it might, but a) one ends up with something that nobody will be able to debug, perhaps including the very person making these changes, and b) if the issue is fixed correctly, there are unknown number of ports to rebuild.

A better option would be to use an earlier version of dependency which was supported on a system of interest (for poppler – pre-C++20 version). Yet better is to fix the build, which should be trivial in this specific case, since very likely it gonna more or less just work with the modern compiler.

P. S. A system with some tweaks added is the same system. There is no 10.5.9, it is still 10.5.8.
 
P. S. A system with some tweaks added is the same system. There is no 10.5.9, it is still 10.5.8.
In fairness, the only difference between 10.5.x and 10.5.x-1 is tweaks. For example, for the difference between 10.5.7 and 10.5.8, I got:

20241022_130938.jpg


just tweaks and fixes, just like Sorbet.

... so, while unofficial, it seems reasonable to bump Sorbet to 10.5.9, which is in fact how is presents itself in "About This Mac".
 
just tweaks and fixes, just like Sorbet.
Apple recompiles the entire operating system on every new build. Every single minor .X release has tens of thousands if not hundreds of thousands of lines of code changed in critical components such as the XNU kernel itself.

On the other hand, Sorbet is not much more than a few changed default settings and the removal of Intel-only binaries.
 
  • Like
Reactions: barracuda156
In fairness, the only difference between 10.5.x and 10.5.x-1 is tweaks. For example, for the difference between 10.5.7 and 10.5.8, I got:

View attachment 2440516

just tweaks and fixes, just like Sorbet.

... so, while unofficial, it seems reasonable to bump Sorbet to 10.5.9, which is in fact how is presents itself in "About This Mac".

So if you change reported value in About this Mac to 14.7, it will be macOS Sonoma? )

Perhaps output of `sw_vers` and `uname -a` will be more meaningful.
 
So if you change reported value in About this Mac to 14.7, it will be macOS Sonoma? )

Perhaps output of `sw_vers` and `uname -a` will be more meaningful.
@ChrisCharman's first response is correct, AuroraTrimcelerator is the ancestor of Sorbet. If I recall, some tweaks from Aurora were omitted in Sorbet because they were found to actually decrease performance in certain situations, while several new ones were also added onto the tweaks originally packed into Aurora, and then built into the disk image. On top of all the more arbitrary cosmetic addons in Sorbet like themes, screen savers, some app updates, etc. Plus the app store frontend.

But on a more abstract note, with respect to Aurora being the main component ... while my focus these days has largely moved on from Sorbet and the other projects, even as personal interests, I do regret that there was always some misinformation and / or animosity surrounding it (namely that it was literally just 10% tweaks and 90% hype, because Aurora didn't contain that many tweaks), in hindsight probably due to insufficient transparency and an overdose of the marketing -- because hey, marketing is fun and it's fun to wear a costume and pretend to be Apple; there's little reason to do anything that you're sacrificing so much free time for if it wasn't in some capacity fun, at least in my opinion.

Regardless, I hope the first paragraph contributed to Chris' response in answering your question, @mac57mac57. I'm happy to provide detail on anything else to the best of my ability, if you'd like.

@mac57mac57 I can't remember at this point what exactly Aurora did, so I went back to take another look at its contents one by one:

1. It removes AudioIPCDriver.kext, AppleI2SModemFamily.kext, and IOSerialFamily.kext, and then clears the kernel cache. Removing AudioIPCDriver does reduce idle CPU usage, but removing the rest pretty much only increases available disk space, and also reduces the time to poll all of the kernel extensions in the system -- which is only run, like, once during first boot. Either way, this was included in Sorbet.

2. It removes all instances of 'designable.nib', which I guess is leftover debug code that Apple left in the released system instead of being cleaned out prior to release. Again, this should only save space. Maybe it reduces application launch times by a small amount, but that's a stretch. This was also included in Sorbet.

3. It disables BeamSync, which is essentially Apple's custom implementation of V-Sync. Doing this will result in smoother 2D animations, in most cases. This was disabled by default in Sorbet.

And then it repairs disk permissions and runs the BSD periodic maintenance scripts. That's the main script.

4. The 'Disable Spotlight' script used a cruder and less refined method by actually taking out Spotlight from the system ... without addressing launchctl, so the console would just fill with constant errors of mdutil wondering where the files are because the responsible daemon processes weren't shut off. A more correct implementation of this was included in Sorbet, where the files weren't touched, in favor of just the daemons being properly switched on / off via launchctl.

5. 'Optimize Network Speeds' used a more primitive configuration of various sysctl parameters to modify the behavior of the kernel network stack to get higher performance, regarding how it transmit and received data. I believe a more finely tuned version specifically for the version of Darwin shipped with Leopard was included in Sorbet by default. Or something like that.

6. The 'Enable QuartzGL and Quartz 2D Extreme' script was mostly a misunderstanding. Quartz 2D Extreme was just QuartzGL's moniker during the Tiger era, and this script actually enables both of them, so it would theoretically 'work' across both Tiger and Leopard. It was believed at the time that enabling it (QuartzGL) system-wide would enhance graphical performance and was planned for Sorbet, but it was found during final testing that in the majority of cases, applications running with QuartzGL enabled would present around the same performance as otherwise, but with higher resource consumption, so it was just disabled for everything. I think the one exception was the System Preferences app, which would display preference pane transitions noticeably choppier when QuartzGL was disabled.

7. Monolingual was used to strip non-PPC architectures from the Sorbet image, and a generic alternative to ShadowKiller was also included in Sorbet (somewhere in the Scripts folder) but not enabled by default. Enabling this should moderately improve 2D graphics performance even further.

And then the contents of 'AuroraTips' were tweaked / added to and then rebranded as 'Sorbet Tips' and plastered onto the Mac Garden page. And that's pretty much everything between them.

I was still learning, so I didn't fully understand at the time that making the system itself consume less disk space didn't really make it faster, rather instead it usually just breaks things. In a nutshell -- and with some exceptions, what has been proven to generally make software faster (relative to the hardware it's running on; you won't feel the difference if the hardware is overpowered for the software in question) is how many CPU threads it consumes, how much memory it consumes, and how much it leverages vs. strains the GPU.

I hope that was helpful.

To be fair most people don’t understand what sorbet actually is, and @z970 is being more transparent now, so any questions should be addressed to them directly.
 
Last edited:
To be fair most people don’t understand what sorbet actually is, and @z970 is being more transparent now, so any questions should be directed to them directly.

While, importantly, I cannot confirm this personally, at least some users mentioned that using “Sorbet” led to certain breakages (some 3rd-party software failed to build, also there were FW-related issues).

But my point was not that in fact – it is perfectly okay to modify the OS for oneself and for other users, as long as they are aware of that and willing to use it, and it is possible that modified 10.5.8 may work faster in some scenarios and have updated security certs or what’s not.
It is rather that if something fails to build on “10.5.9” specifically (but not on the unmodified 10.5.8), then it should be reported to whomever develops those mods and not in a general thread. But in most cases (like here in particular) all those minor tweaks are simply irrelevant, and the build fails on 10.5.8, which is what matters.

P. S. If anyone has examples of something building and working on “Sorbet” but failing on 10.5.8, please update me, that will be useful to know.
 
Had the same idea some days ago, but we deinstalled the original X11 from apple, installed Xorg-xserver-legacy, so gimp is not starting as an application.

From XQuartz page it seems that it is possible to have both X11 and switch between the two, but in practice, I think, that is a recipe for breaking a lot of stuff in a hard-to-debug way. An obvious problem is the following: a software may end up using wrong headers or linking to wrong libs, when more that one version exist in standard system paths. Now, it is not hard to check what something got linked to, but there is no way to know which headers were used post-factum (unless logs are preserved).

However, if the question is how to test different X11 realizations on their own to pick a suitable one, then perhaps make clones of the OS and install Apple X11 on one, XQuartz one on another and MacPorts one on the third.
 
@barracuda156, your point seems much clearer now, and I agree. 10.5.x, all of it, are versions of Leopard, and I *assume* that if something failed to build on 10.5.9, it would also fail to build on 10.5.8. I have not tested this however; I only have "vanilla" Leopard (10.5.8) on my G5 Quad and on a G4 Cube.

Neither of these systems has Mac Ports on them because neither would run it particularly well. My Quad's cooling system is failing... installing and building Mac Ports stuff would "make its head explode" from overheating. The G4 Cube is just too slow for it... some ports take HOURS to build on my G5 DP 2.3 GHz; I suspect it would be DAYS, if even possible, on the Cube.

So, while I agree that 10.5.9 is simply an (unofficial) upissue of Leopard, adding the "Sorbet" moniker to it is just fine to me at least.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.