Qt 5.2 on Mac OS X

I had mixed experiences trying to install Qt 5.2 on two different Macs (both running the same version of OS X): on my personal computer the install went on with no trouble.  I ran an update using Qt's maintenance tool app, and then the package manager in the same app to select the bits of Qt 5.2 I wanted to install; my work computer, on the other hand, game me a lot of trouble. So, for future reference, here's how I got it working.

Problem 1 – Update did not complete

The update process was failing with an error pertaining to the system not being able to save the Updates.xml file due to it already existing. As far as I could determine, the update app creates a temporary directory for each repository—at /var/folders/rb/[random string]/T/remoterpo[some ref. code]meta/—and saves Update.xml file in there, before listing all the available updates. Due to either a bug in the maintenance app or an incorrect update package, one of the repositories was causing this error.

Solution

On the maintenance app's main window, select Update Components, then Settings, then Repositories, and turn everything off except for one, the Maintenance Tool online repos.  Run the update, and that should complete with an updated maintenance app. Then re-run the update process with all repositories selected, and it should go to completion. After this point you should be able to restart the app, select Package manager, and the Qt 5.2 packages should show. That leads into the next problem I encountered.

Problem 2 – Installation fails

The installation process either via the maintenance tool or using the installers from the Qt website fails some time midway with the message "Command install_name_tool failed," followed by a list of arguments to the command.

Solution

If you search the web for solutions you will certainly bump into posts asking "Have you updated Xcode?".  Well, I had. But there's more to it. On my work computer I had to install the Xcode Command Line Tools, which can be found in the Xcode preferences, under Downloads. Once I completed this step, the install worked fine. Strangely, this step was not required in my home computer (same OS X version): I just checked, Xcode Command Line Tools are not installed. Go figure.

Coming Home

Coming Home, a set on Flickr.

Took possession of our little racer. First thing we did was give it a good wash, and then we brought her in the garage to check out the state of the brake lines. Both rear lines are rusted through.

Volume Image Transfers in OS X

I've been frequently faced with the need to copy an image (usually a CD iso from some sort of installer) into a thumb drive, mostly due to the fact that I have a few machines that don't have a disk reader at all.  Yet this doesn't happen frequently enough that I actually remember all the steps, so every time I have to search and find this info again, which is not very efficient.  Hence this short note to myself here, where it might end up being useful to others as well.

In this case I want to copy a recently downloaded copy of a Linux installer .iso image to a USB thumb drive, so I can install it in a laptop.  We'll use the terminal in OS X, and the command line tools dd and diskutil. The symbol ">" indicates the command line prompt in my system.

From the command line:

> diskutil list

This will list all available volumes in the system, by device.  A typical output might look like this:

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            899.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                100.3 GB   disk0s4
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 GB     disk2
   1:                 DOS_FAT_16 DISK_IMG                1.0 GB     disk2s1

In our scenario, disk1 is the device that will host the image.  In order to access the disk directly for a low level copy—i.e., we're not copying the iso file here, we're loading that image into the device itself, so we can actually boot from it—we'll need to unmount it first.

> diskutil unmountDisk /dev/disk1
Unmount of all volumes on disk1 was successful

The above succeeds whether the volume had been mounted or not.  Next, we copy the disk image to the thumb drive using dd.

> dd if=/Users/beto/Downloads/ubuntu-12.04-desktop-amd64.iso of=/dev/rdisk1 bs=1m

The parameter "if" indicates the input file, "of" the output file (in this case a device), and "bs" the block size at the destination.  Notice I used "rdisk1" instead of "disk1".  In OS X, the rdisk device is the "raw" device, which can be accessed without buffering or alignment checks.  That removes I/O overhead from the process, making it orders of magnitude faster than if you were to use the buffered device.  Obviously, if in this case points to the iso file I am copying in my scenario.  This could also be another device, say if you were making an image backup of a disk.

The results of the copy above are:

698+1 records in
698+1 records out
732213248 bytes transferred in 237.283433 secs (3085817 bytes/sec)

As soon as the process finishes OS X will attempt to mount the new volume.  If the image's file system is not supported OS X will balk at this, showing a warning dialog complaining that the disk is not readable, and showing the actions "Initialize...", "Ignore", and "Eject".  Simply select Eject, and you're done.  Another option is:

> diskutil eject /dev/disk1