Shantonu Sen and I have been working a lot on RPM, and the RPM port in dports. Things are looking pretty good now, I’m doing enough building to have a mock-up of a yum repository (kind of like apt) up and working. I’ve got 10 or 12 packages for both ppc and x86 built, and all seems to be going well so far. Feel free to give it a shot and give us feedback, it’s starting to look pretty slick!
Share on Facebook
|
|||||
|
I’ve got the first release of my prebinding bits working now, it’s a combination of a patch to fink’s perl modules and a couple of packages that implement the post-processing. I’ve got a few people trying them out, when I’m confident they’re at least not breaking anything, I’ll make a bigger announcement to the list. The nice thing about doing things this way is that it’s pretty much all transparent for any package that makes twolevel libraries. Yay! Share on FacebookI got Darwin/x86 set up on my PC a couple of days ago, and I’ve been a building fool since then. KDE works from dports, and I’m in the process of getting the fink packages happy as well. Some details here, in my post to the KDE-Darwin list. Share on FacebookSo I’ve been spending the last week trying to make prebinding happen in Fink. I’ve gone through a couple of stages in investigating things, and I’ve found a number of ways to do it that are inefficient, but none of them seem to be very elegant. I’ve got a couple of ADC support requests left, so I sent this to Apple: The Problem: Currently Fink is entirely un-prebound. I’ve been spending a couple of weeks trying to determine how to make prebinding Fink possible (given the large number of binaries to manage, and how often they are changed). I’m trying to figure out the minimum amount of work that packagers have to do to make prebinding possible, and what will be needed to be changed in the Fink tools to handle the backend. Unfortunately, prebinding on the scale that we’re trying to accomplish is largely undocumented. My first attempt at prebinding involved taking a list of dylibs from Fink and putting them in a file, and running seg_addr_table from cctools on it. Then I would have Fink set: LD_SEG_ADDR_TABLE=/sw/fink/dists/seg_addr_table LD_PREBIND=1 LD_PREBIND_ALLOW_OVERLAP=1 This way, anything that’s already properly . . . → Read More: Ranger Rick’s Amazing Prebind-O-Rama! Share on FacebookI should have been in bed, instead of reading this. 00:33 <keetz> why doesnt darwins df have the human readable flag 00:34 <landonf> keetz: we don’t believe in humans 00:34 <kevinvv> keetz, humans don’t use darwin Share on FacebookLooks like future Apple GCC releases will no longer have the cpp-precomp hack in them. Should save a lot of headaches in porting UNIX stuff. Share on FacebookGot KDE 3.1 moved to Fink stable this morning, so far things seem to be going OK. Also been working on slicker stuff recently — I cleaned up the build system some and made a RedHat RPM spec. You can basically build with a ‘make rpm’ now and get freshly baked packages. =) I’m in the middle of importing the latest prerelease of KDE 3.1.1 into the KDE-Darwin tree. I also sent an updated version of the KDE-Darwin admin patch (including Sam Magnuson’s changes) to kde-core-devel. Lots of administrivia going on, but it looks like things are cleaning up nicely. Once I’m done with the 3.1.1 import, I’m going to take another look at making modifications to KDE’s build system to build the module/binary kdeinit stuff automatically. Still haven’t quite figured out how that’s going to work. Share on FacebookI updated KDE to pogma’s latest libtool patches, the build-time issue with genembed in keramik went away (yay!) and all appears to be well. I’m building kdelibs3-ssl 3.1.1 right now (against a prerelease tarball) and have found what I think are the last of the build bugs in 3.1.1. He also added dyld support to libltdl, but I haven’t integrated it with kde’s personal version of it yet. Share on Facebook |
|||||
|
Copyright © 2024 Tales of the Raccoon Fink - All Rights Reserved |
|||||
Comments are closed 