109
edits
Joel Reymont (talk | contribs) No edit summary |
Joel Reymont (talk | contribs) |
||
| Line 7: | Line 7: | ||
=== August 27, 2009 === | === August 27, 2009 === | ||
The dyld shared cache lives in ''/var/db/dyld/''. The two files of interest are ''dyld_shared_cache_i386.map'' (for x86-32) and ''shared_region_roots/Applications.paths''. Both are regular text files. The former shows the contents of the shared cache for the i386 architecture and the latter is what ''update_dyld_shared_cache'' inspects. | The dyld shared cache lives in ''/var/db/dyld/''. The two files of interest are ''dyld_shared_cache_i386.map'' (for x86-32) and ''shared_region_roots/Applications.paths''. Both are regular text files. The former shows the contents of the shared cache for the i386 architecture and the latter is what ''update_dyld_shared_cache'' inspects. | ||
There's no prebinding on newer versions of Mac OSX and the dyld shared cache is | |||
automatically updated as needed. Tracing Safari disk activity during startup | |||
reveals that basically all its dynamic libraries are pulled from the dyld | |||
shared cache. | |||
It's possible to add Firefox (''.../Firefox.app/Contents/MacOS/firefox-bin'') to | |||
Applications.paths and the change will be kept across reboots. Unfortunately, | |||
only a handful of libraries that Firefox uses are pulled into the cache by | |||
update_dyld_shared_cache. I'm speculating that this may have something to do | |||
with @executable_path/XUL and friends (otool -L .../firefox-bin). | |||
Safari uses absolute paths to frameworks in ''/System/Library/Frameworks'' so I | |||
speculate that relative paths are what is preventing XUL and others from going | |||
into the cache. We may want to investigate | |||
''/System/Library/Frameworks/Firefox.framework'' or similar. | |||
[https://bugzilla.mozilla.org/show_bug.cgi?id=513076 Bug 513076]. | |||
= Previous statuses = | = Previous statuses = | ||
edits