I hadn't updated/upgraded for a while, and I realized I was going to have a whole bunch of packages to build. I thought I'd see if I could speed up the process a bit by using a ramdisk for the build directory, since compilation tends to be I/O-bound. I had a minor hiccup with GNU libtool, but I was able to patch it and make things work (and work pretty fast). Here are the details.
First off, here are the commands I used to create the ramdisk and mount it: dev=`hdiutil attach -nomount ram://2097152` newfs_hfs $dev sudo mount -t hfs $dev /opt/local/var/macports/build That creates a 1GB ramdisk (the number after ram:// seems to be the number of 512 byte blocks), creates a filesystem on it, and mounts that filesystem over the build directory. I originally used a 512MB ramdisk, but one of the packages I was building (apple-gcc something, I think) ran out of space. I had that set up and left things running overnight only to find it sitting and spinning in the morning because GNU libtool (/opt/local/bin/glibtool) couldn't create a lock file. The problem was that libtool foolishly assumes that the build directory must be on the same filesystem as the libtool script itself. It tries to create the lock file as a hard link to itself. Naturally, this fails across filesystems. I had to modify glibtool in two places so that instead of using ln it used ln -s and created a symbolic link to itself. On my system, it was lines 2584 and 4155, but that may vary in other versions. Just find where it is trying to make a lock file and sleeping until it succeeds (search for sleep) and modify the ln command creating the lock file. That's all it took, though, and my upgrade is chugging along nicely. When everything is done I can eject the ramdisk from the Finder or use diskutil. Best of luck to anyone else who wants to try this approach. --Greg _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
