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

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

  1. I really don’t like Apple Support Communities. Their general answer for everything is “Backup and reinstall OS X” forgetting that most users of any OS are trying to avoid doing that by going there in the first place. Backup and reinstall is not a fix, it’s giving up. You are not putting on a bandaid, or healing the problem, you are amputating the limb and replacing it because you do not know the source of the issue or how to fix it. You then get very highly regarded 10,000 point plus users on ASC that have basically fixed over half of their problems simply by sitting there and copy and pasting “Backup and Reinstall” into every OS issue thread.

    Yes it works, but it’s a last resort, and in the eyes of any suitably computer literate user, it is counterproductive in any other instance.

Please comment. I really enjoy your thoughts!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s