KDE4 Progress

I’ve been making good progress on getting KDE 4.4 (release candidates) working. It’s been quite an interesting ride, in both a good and bad way. =)

First, there’s the fun of 10.6 making it even harder to have code that forks without it accidentally exploding on the CoreFoundation fork-without-exec prohibition. I was able to solve this with a combination of fixes from macports’ kdelibs4, and some of my own code which changes things to use low-level POSIX APIs instead of Qt APIs for some bounds-checking before execution.

Next, there’s the fun of Phonon. KDE 4.4 requires a newer version of Phonon than what ships with Qt (even Qt 4.6). On OSX it gets even hinkier, since the QuickTime plugin for Phonon requires private Qt headers, so the only sane way to build it is to build the Phonon included with Qt, rather than building it as a separate project.

I ended up adapting a patch the Kubuntu folks use to inject a . . . → Read More: KDE4 Progress

Share on Facebook

New KDE/Mac Build

So there was a little bitrot since my last packaging run in November, but I’ve finally managed to get a new KDE build done. If you’re downloading in pieces, Qt and kdesupport have been updated too, so make sure you grab them as well as whatever else you’re looking to install.

It looks like starting from the Finder works again, so my patches haven’t totally rotted, and one big new thing is working — input methods!

Unfortunately, SSL is still not happy, I’ve not had a chance to investigate yet. Otherwise, though, things are looking up. Please give them a shot and let me know if you run into any issues, and if you’re willing to help out, join us on irc, in #kde-darwin on freenode.

Share on Facebook

Share on Facebook

Fink 0.25.0 Out

For the first time since early 2005, a new major version of “fink” the command-line program is out. Plenty of good development work has gone on in the 0.24 series, with lots of nice incremental updates, but a lot of really great stuff has gone into 0.25. While there are plenty of other neat engine things and additions, I’m going to focus here on the changes that users will be able to see.

Internals Speed

Most noticeable right away is speed. The incremental indexer was pretty much rewritten. You will not spend nearly as much time nowadays waiting for fink to scan your info files for changes.

A lot of other smaller operations related to the index have been sped up as well. All in all, fink is much faster. (Although I still would never call it “snappy”… <grin>)


The buildlocks system has been rewritten, and should rarely get in your way anymore. It is much smarter about adding and removing build locks, and can clean up after itself much better.


There are a number of new options for various things.

–log-output Automatically log the output of package . . . → Read More: Fink 0.25.0 Out

Share on Facebook

Smooth Sailing with Leopard

So we’ve been working frantically to get Fink things up and running in a basic way on Leopard. I’m told that Fink HEAD now bootstraps cleanly, and we’ve been slowly working our way through smoke-testing building various things.

For the most part, it’s been really smooth, compared to this time in the previous cycle. The Tiger WWDC preview was nearly unusable; it was enough to get a taste of things to come, but so much was broken at the system level that it was hard to get things working reliably. It took a number of seeds before we could really do much work on 10.4.

That’s definitely not the case on Leopard. Other than a few minor buglets, stuff has been working remarkably well. I’ve probably only had to tweak maybe one in ten packages to get where I am, and those have been minor changes (mostly standard fixes related to POSIX compliance — “#include <sys/types.h>” and such).

I’ve managed to get a decent amount of KDE/X11 built, and it seems to run just fine:


Share on Facebook

Share on Facebook

Out with a Bang, In with a Whimper

It’s funny how what should have been one of the greatest open-source PR moves since Netscape opened up the mozilla codebase instead feels like “too little, too late.”

Apple has announced Mac OS Forge, a project to do what OpenDarwin was already essentially created to do. It comes on the heels of months of bad PR about Apple failing to put out the X86 kernel source, and OpenDarwin shutting down due to a lack of communication between Apple and the open-source community and a lack of community involvement in general (other than a few specific exceptions like dports and WebKit).

For a company that’s done a great job of getting developers excited about their platform, this really shows they don’t understand the community they’re trying to get help from.

The most important thing you can give an open-source developer is the feeling that he’s doing something with impact; that he’s donating his time to something that others will appreciate and find useful. He wants to know that the work he’s doing goes, maybe not into the public domain, but into a . . . → Read More: Out with a Bang, In with a Whimper

Share on Facebook

Apple Intel Assembly Frustrations

For the most part, the x86 transition has been really smooth. Only minor changes needed here or there to make things work. But there are a couple of places where it’s clear they didn’t spend much time looking at their infrastructure. Assembly is one of them.

I can’t imagine they didn’t think “Well, there’s all this linux x86 code out there that’s gonna suddenly be enabled when people start building things. Perhaps we should make sure stuff works.” but apparently they didn’t. 🙂 There are some obvious things, like Apple’s gas being very old and heavily modified, that should have set off warning signals.

For example, Apple’s gas has no “.balign” keyword. Instead, it has “.align”. So if you used to use “.balign 16” you now use “.align 4”. Similarly, “.balign 8” becomes “.align 3”.

Also, apparently the AT&T-style “.rept” and “.endr” are not supported, even though they work everywhere else. So now this:

__asm__ __volatile__ ( “.rept 8 \n\t” “(something) \n\t” “.endr \n\t” );


__asm__ __volatile__ ( “(something) \n\t” “(something) \n\t” “(something) \n\t” “(something) \n\t” “(something) \n\t” “(something) \n\t” “(something) \n\t” . . . → Read More: Apple Intel Assembly Frustrations

Share on Facebook

Updated Cross-Compiler

I’ve updated my linux-based darwin cross-compiler/distcc suite; the packages should be a little more maintainable and are now separated into 10.3 and 10.4 packages. One thing to note, these packages will only work on 10.3 if you use the odcctools ld, 10.3’s ld from Xcode does not understand the relocation entries created by the odcctools assembler and such.

I’ve built packages on CentOS 4 and Fedora Core 5, and I have access to a whitebox 3 system that I can build RHEL3-compatible packages on as well. If any of you have other systems that you’ve been able to get things to build on, please e-mail me.

Share on Facebook

Share on Facebook

Cross-Compiling Darwin

So I’ve been working on getting a reasonable cross-compile of GCC from XCode 2.2.1 working on Linux so that I can distcc to my Linux boxes from my mac when doing long compiles (*cough*KDE*cough*). I’ve finally got something useful enough for myself that it’s worth seeing if it works for anyone else.

So, uhh… check out my spiffy linux/darwin cross-compiler here!

I ended up making a little tool that automatically translates various gcc references into the canonical target name of that compiler, so it’s safe to distcc to other oses (ie, instead of calling “gcc-4.0“, it turns it into “powerpc-apple-darwin8-gcc-4.0“). This script is now part of my distcc package in unstable as of tonight.

Please, give it a shot, and let me know if you run into any issues. Happy compiling!

Share on Facebook

Share on Facebook

Fink Updates

Yes, it’s been quiet, but I assure you, I’ve been busy. Figured it’s time to post an update as to what’s going on.


I’ve got Mono 1.0.1 all put together, just need to do some final testing and put it out. Sorry, there still is no modern mono on 10.2-gcc3.3, it refuses to build and I haven’t found a solution yet.


I got various builds of KDE 3.3 beta working, and it seems to have shaped up pretty well. KDE 3.3 is being uploaded right now and will go live very soon, I’m working on getting everything updated to KDE 3.3 final and I’ll see if things will be ready for release… well… sometime. 😉


It looks like the major problems in the PostgreSQL packages have been ironed out now. I’m working on putting together a PostgreSQL 8.0 package, too, with the 8.0 beta.

X.org X Server

The new release of the X.org X Server is coming, and I’m going to work on packaging that up as . . . → Read More: Fink Updates

Share on Facebook

Sunday, Medium Rare Sunday

It’s a nice lazy Sunday afternoon. My roommate and I got a grill, we’re cookin’ up burgers, and it’s a nice 66 degrees outside. I’ve got an XFree86 4.4 package working, it seems to run really nice. It’s pending inclusion in unstable after we decide how we want to handle the licensing issue. The main question now is, do we stand with the other distros in not releasing 4.4 packages so that XFree86 is more likely to unkink their licensing, or do we release anyways (since it seems like, at least, there isn’t a conflict anymore)? Also, I’ve basically got KDE 3.2.1 done now. I’m finishing up the test builds on 10.3, but I see no reason it won’t be releasable to coincide with the tarball release from the KDE folks. I’ve got my KDE/Mac toolset put back together and I’m through kdelibs in building everything again (including an update to Qt 3.3.1, I’ve gotta get packages put together and up on the KDE binary page). Things are moving along in a generally forward direction, as mom would say. I’ll keep you posted when I get new KDE/Mac binaries together and ready for perusal.

Share on Facebook

Share on Facebook