The license key for EAGLE v7 having come through today, I figured I'd install it and have a go.
Oops! It wants glibc 2.14, and it looks like I have 2.13. Foo.
Well, there's a new Debian-stable, just came out in June, that probably has more up-to-date libraries. Many, many pages of instructions for the upgrade-in-place.
Guess I'd better get sundry critical stuff out of the way, and then do the magic dist-upgrade. Like, later in the week.
Meanwhile, I'll try the new EAGLE in a VM. VMs are the answer to everything, right?
And maybe I'll try upgrading my laptop before the workstation; not only is it less critical, but it has a smaller hard drive, so perhaps I can back up a disk image for Just In Case.
Update: Possible alternative approach here is to download the source code for the latest glibc, and build it locally. Then configure the loader, and so on: details. Got glibc-2.21 compiling now, and if I watch the output scroll by I get seasick. Csick. Glibcsick. One of those things.
Update 2: OK, so that was a bad idea. I installed the new glibc under /opt, so as not to clobber anything... but after I added it to the ld.so configuration, while I can still launch some third-party applications (and, indeed, ldconfig), things like mv and rm are b0rked. Guess I gotta break out a bootable CD and fix this....
Update 3: Recovery was complicated by the fact that everything other than boot and swap live in an LVM partition, and the first two bootable CDs I found don't speak LVM. I was starting to think I'd have to pull the drive and connect it to my laptop, but then I found the Debian-Wheezy netinst disk wherefrom I'd done the installation in the first place, and that had a rescue option that almost got me to a shell on my root filesystem, and from there I could alt-F2 to a shell, muck about on /target, run ldconfig (good thing it wasn't broken! It wasn't provided by the netinst CD) with -r /target, reboot, and be back on the air. From glibc malinstall to recovery complete: just about 50 minutes of abject panic.
Gah. Good thing I hadn't scheduled any real work for today. Once I get calmed down, there's plenty in the queue, though.
Update 4: In preparation for some of the work in the queue, connect the newly-purchased debug pod, via the newly-built adapter, to the intermediate-model target hardware (the final model, whereon most of the upcoming work must happen, being out for build at the moment). Seems to work. Attempt Ethernet communication with the target device: nothin'. Eep?
Oh. When I rebooted the workstation, the required IP alias went away; a simple
root@magrat:~# ifconfig eth0:1 192.168.1.1
later, it's working just fine.
Aside from which, I realize that the project I didn't quite get signed off last week actually has two more items that need ticking off; one should just require about half an hour on site, while the other involves, among other things, buying some mildly arcane SMT resistors, which means a Digi-Key order, local OTC sources not having them. Shoulda done that Friday, really, but on Friday I was rather distracted by family matters. So: order placed, a little late in the day, and depending on client priorities I may need to make two trips to the site, or just one trip next week.
Update 5: At least I didn't have as bad a day as these guys. Being able to shut down the computer and spend half an hour sorting out the problem is a luxury. Most real-world things don't have pause buttons.
Update 6: Fry, fry a hen. Forget the very-latest glibc; build 2.14, since that's what EAGLE demands. Also, don't add it to ld.so.conf; instead, try:
eric@magrat:~$ LD_LIBRARY_PATH=/opt/glibc-2.14/lib /xfer/cad/eagle/eagle-lin64-7.3.0.run
Hooray! It runs the installer! Then invoke the application with:
eric@magrat:~$ LD_LIBRARY_PATH=/opt/glibc-2.14/lib /opt/eagle-7.3.0/bin/eagle
And it works!
I still gotta upgrade to the current Debian sometime, but it doesn't need to be this week. (And I should probably try it in a VM first, just to make sure it doesn't break my Ruby stuff.)
Update 7: As a footnote to Update 5, testing & debugging real-time control systems can get Really Interesting when the timescale for things going horribly wrong is in the tens of nanoseconds... especially when there's a variable lag of several seconds or so after the nearest identified precursor event. On the other hand, such failures can often be repeated as needed, in a controlled setting, without actually destroying anything.
Comments