Oct 6
64-bit Hell and Eclipse
For many years now I’ve had an AMD box that was capable of running 64-bit. I wouldn’t say I’m an early adopter, it just happened to be capable of 64-bit and it didn’t bother me if it was a feature or not. At the time I tried out the 64-bit builds of Linux and Windows, found Windows woefully equipped to handle 64-bit and Linux a bit better (having all of the source code to recompile and fix things on a new word size does help things).
Fast forward to today and I have (again) a AMD AthlonX2 64-bit box now on my desk and I’m running SLED10 64-bit. To be honest I’m doing better than Helpdesk who has a similar test box and have been trying to get 64-bit Windows XP up and running on the machine. They’re still hunting for drivers for the thing and keep complaining they have to go halfway across the internet to get things. For myself I’ve only downloaded one driver for the ATI graphics card on it, more to get dual head mode working on the graphics card. So I’m up and running and I’m not really noticing any issues with applications. Everything I’ve thrown at this box has been handled perfectly, until I decided to upgrade Eclipse. Eclipse is a strange beast and the build I have is a 32-bit build. It worked fine by default, however the Java version that I have on my desktop is rather ancient (1.4.2, thank you SuSE). This meant that some things didn’t want to work properly. I tried to upgrade to the IBM provided 1.5 release which wanted to be 64-bit. Which is fine, until you realize that the Eclipse build has a 32-bit SWT support layer. Try again! So I ended up downloading the 32bit Linux Java off the Sun website and installing it. That got me up and running with 1.6 and Eclipse started and almost got me to where I wanted to be. Then Eclipse hanged itself. Eclipse does this from time to time, so I just let it sit there and do what ever it
does and it came good. I have a feeling its trying to go to the internet or some other network resource which is taking its sweet time to respond, or for the internet, being blocked by a firewall somewhere.So this brings to light an issue with any system that indulges in dynamic linking. One of the issues here was Eclipse’s SWT library being 32-bit (there are 64-bit builds so that is fixable though I know not how) and at one point using a 64-bit build of Java. Funnily enough this isn’t as big an issue on my platform of choice, Mac OS X. As I pointed out in a Slashdot comment Apple has done a great job of shifting architectures for their operating system and let alone the 32-bit/64-bit transition. They’ve had to move from their original Motorolla m68k powered machines to PowerPC based machines and now from PowerPC on to Intel, and they’ve used emulation both times swapping from the m68k to PPC and then from PPC to Intel to make the transition lighter, and utilizing “Universal Binaries” similar to the “fat binaries” they used previously to get things up and running. The only other element of note is providing the “Classic” interface to ease the transition from the nanokernel that powered Mac OS 9 and earlier to OS X’s new XNU microkernel. The system is in effect emulating a Classic machine, though it isn’t complete. Though of most note Apple announced the toolchain to make the PPC to Intel switch all possible ahead of time and integrated it directly into their primary developer tool, XCode.Perhaps this is why Apple’s transitions are so much smoother than that of either Microsoft or Linux.
No Comments
Leave a comment