dyld: shared cached file was build against a different libSystem.dylib, ignoring cache


After my last update of OS X 10.8.5 my terminals were flooded with above message – like twenty-ish lines when I started and up to six times after each console command I issued, making it impossible to work with the console anymore.

The error message also told me to run update_dyld_shared_cache and restart my machine. That’s what I wanted to do, but when I issued the command this is what my computer presented me with:

pygospa@lalaith ~ % update_dyld_shared_cache
update_dyld_shared_cache failed: you must be root to run this tool

So I switched to my administrator account which who is in sudoers and typed in the command again:

eru@lalaith ~ % sudo update_dyld_shared_cache
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libtidy.A.dylib in shared cache because it is not owned by root
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libncurses.5.4.dylib in shared cache because it is not owned by root
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libutil.dylib in
 (...)

There where at least 50 of those lines, and as it seemed nothing had been done, so I checked the permissions and as it turned out, all files in /usr where in possession of root except for /usr/lib, which belonged to the administrator. Huh, that’s strange. Anyway, let’s run it with the rights of the administrator then:

pygospa@lalaith ~ % update_dyld_shared_cache
update_dyld_shared_cache failed: you must be root to run this tool

Okay, I actually don’t like changing owners on a Mac, as it might break something, so my first try was to just make the files writeable for everyone. So I switched to /usr/lib, entered a chmod 777 * and got a bunch of permission denied responses:

eru@lalaith /usr/lib % chmod 777 *
chmod: Unable to change file mode on cron: Operation not permitted
chmod: Unable to change file mode on libCoreStorage.dylib: Operation not permitted
chmod: Unable to change file mode on libIOKit.A.dylib: Operation not permitted
(...)

Coming from Linux this is really strange, as eru was in possession of all those files… I tried making the directory writeable for everyone – with the same effect. Okay, let’s switch to root – root can do anything.

You’d think…

root@lalaith # l /usr/lib
drwxr-xr-x 316 eru wheel 10744 15 Sep 18:33 lib/
root@lalaith # chown root /usr/lib
chown: /usr/lib: Operation not permitted

Okay. Now I was really puzzled. What the frack is up with this strange behaviour? I did, what any good Windows User does, when he encounters a problem. I rebooted. Same old, same old. Next stop: Google-Town.

Tried sudo update_dyld_shared_cache -force and sudo update_dyld_shared_cache -root / -force, sudo update_dyld_shared_cache -verify

(…)If you suspect the shared cache is somehow corrupt, you can run: sudo update_dyld_shared_cache -verify which re-creates the cache and compares the result with your actual cache file.

and a bunch of other stuff. Nope. Okay, Apple Support Communities, hosted under discussions.apple.com – sometimes they have pretty good answers. And yep, there was someone with the same problem, and there was an answer marked as “solving my questions”, and it was short, and it just said… what?!

You have a missing or damaged system file. Back up all your data, then boot from your installation DVD and reinstall the OS. Your data will be undisturbed. After rebooting, run Software Update to bring everything up to date. You may have to run it more than once.

You’re kidding. I don’t have time for this, seriously! Fracking Mac, fracking Apple, to hell with this load of crap! I was really angry.

Fortunately I don’t follow instructions straight away, and after a lot of head aching googling and cursing the day, I came across Safe Mode.

Starting up into Save Mode does several things:

  • (…)
  • Mac OS X v10.5.6 or later: A Safe Boot deletes the dynamic loader shared cache at (/var/db/dyld/). A cache with issues may cause a blue screen on startup, particularly after a Software Update. Restarting normally recreates this cache.
  • (…)

Sounds related – and yeah, it solved my problem! Starting into Save Mode is pretty easy: Power down, hold the “Shift”-Key, Power – and keep holding the “Shift”-Key for quite a while – untill the Apple logo appears.

It’ll then take a while – at least on a recent, souped-up Macbook Air it was enough time to brew a new cup of coffee. But it actually came up, I logged in, and: Hey! In Safe Mode the annoying message is gone! Reboot, and yeah, in Normal Mode everything’s back to normal.

Advertisements

Automating Mac OS X notebooks


I just found this pretty neat script for Mac OS X to auto-mount network filesystems, according to your IP. Nothing fancy, but as most of the Mac users are not familiar with scripting, it’s a nice thing to try out 😉

The script checks wether you are in the right network by determining your IP (which therefore needs to be a fixed IP, provided by a DHCP server/router). You could of course also use wild cards, but I guess this is the better solution (ideal if it is something fancy, not that common, so no 192.168.0.x) – but you’ll figure something.

set myip to do shell script “ifconfig | grep ‘broadcast’ | awk ‘{print $6}’”
if myip = “10.168.1.255″ then
     mount volume “smb://workgroup;username:password@10.168.1.254/path/”
else
     display dialog “Not able to connect server” buttons {”ok”} default button “ok”
end if

The example uses 10.168.1.255 as client address in line 2, so this is what you’ll need to change. The other line that needs adjustment is line 3. You of course change “workgroup” with the name of your workgroup, “username” and “password” accordingly, and after the @ there’s the IP of your server, and the path to that share that you want to mount.

That’s all there is, no magic. If the connection for what so ever reason does not work, you’ll get a dialog window, saying “Not able to connect server” that you can click away with “ok”.

Windows Mail and windows Calendar


I made a funny new discovery, when I had to fix some program associations in the “Set Associations Control Panel” in Windows Vista at work. There are two new tools that are provided with Vista, called “Windows Mail” (German version) and “Windows Calendar” (German version).

“Windows Mail” was disabled by GPO at work as we use “Outlook”. But I was curious, so at home I asked my girlfriend to show me that tools (she has a Vista that was preinstalled on her Laptop – and she wouldn’t trade it for a nice neat Linux 😦 ). Interestingly both tools, “Windows Mail” and “Windows Calendar” looked pretty familiar to me.

It looks pretty much like the tools in Apples Mac OS X (Company’s website), called “iCal” and “Mail”. So I just wandered about the integration of these tools – are they really a copy of Mac OS X tools? Do the new Microsoft tools work so neatly together as in Mac OS X? Which is the actual power of these tools – each individual tool isn’t that of a great invention – there would be better alternatives for each – but they unfold their power when working together
Continue reading