Building on a ramdisk

Gregory Seidman gsslist+macports at anthropohedron.net
Sat Nov 5 09:29:50 PDT 2011


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



More information about the macports-users mailing list