Skip to content

Putting the cart before the horse

So, one of my friends at work was complaining bitterly after I tricked him into installing 64bit Ubuntu on his shiny new xw9300. He knew flash wasn’t going to work, but wasn’t so enthused when he found he’s lost the ability to use copy-and-paste with VNC. He uses the vnc server extension – but that somehow managed to use long when it should have used CARD32 or something like that – so the vncconfig utility can’t talk to it. The real killer is that gdb is very broken with respect to 32bit programs and often can’t inspect variables on the stack. I believe he’s had other problems too and is imminently going to start again with the 32bit version.

I run 64bit Ubuntu on my work machine and it’s been pretty much problem free (although I am also led to hate gdb from time to time) but at home I would not be so foolish. Consequently, I’ve done things a little bit differently.

When I got my shiny new athlon x2 machine at the beginning of August, I knew I wasn’t going to just install a 64bit distro on it – there’s no official 64bit Slackware and I didn’t want to see flash and realplayer disappear, so I figured I start off with a 64bit kernel and then consider my options. After building a 64bit kernel in a VM (yay!), I was suitably unimpressed to see that the compatibility ioctl layer had enough holes in it that I couldn’t use the system properly (iptables refused to apply multi-port rules and hidd for bluetooth input devices just didn’t work). So I abandoned the idea for a while. Then a couple of weeks ago, I decided that I’d have a go at building a 64bit chroot to run the programs that had to be 64bit – and this has turned out to be a pretty effective way of dealing with the problem.

I took slamd64, the unofficial 64bit slackware, and installed its base into a directory and then used bind mounts to make /dev, /sys, /proc, etc available and then wrote a simple script to run stuff out of the chroot (not as fancy as the one recommended for Ubuntu/Debian), and then pointed the calls to the offending utilities at the chroot, and, somwhat amazingly, everything worked. I was particularly impressed to see my 64bit hidd working alongside the 32bit hcid and sdpd. I’ve also successfully run 64bit Unreal Tournament 2004 out of the chroot – which was rather nice.

I don’t think there’s anything particularly profound about any of this, but I find it interesting that the “page-in” approach to 64bit isn’t one that’s been used very much, if at all.

{ 1 } Comments

  1. James Henstridge | 21st September 2006 at 19:02 | Permalink

    Surprisingly, the VNC problem is probably due to using a 32-bit variable to represent a 32-bit value when it should be using a 64-bit long to represent the 32-bit value.

    The xlib API for reading/writing data from a selection lets you specify format of the data as 8, 16 or 32, which cause the data to be represented as an array of chars, shorts or longs respectively, converted to the native byte ordering. This was all very logical on 32-bit systems since the sizes of those types correspnded to the formats.

    But on an LP64 system, it means that the data won’t be tightly packed for format=32. You can’t just take an array of 32-bit ints and stuff it into the selection without losing half the values (and reading past the end of the buffer). Similarly, if you treat the value returned by XGetWindowProperty() as an array of 32-bit integers, you’ll only see half the values and the other half will look like zeroes.

Post a Comment

Your email is never published nor shared. Required fields are marked *