Hi Joel, *; On Wed, Aug 25, 2010 at 10:24 PM, Joel Rosdahl <j...@rosdahl.net> wrote: > On 2010-08-23 13:35, Christian Lohmaier wrote: >> [...] Using mmap [on Mac/PPC] to load all the include files bypasses >> the filesystem cache [...] > > Ouch. That surprises me. Thanks for telling!
You're welcome :-)) > [...] >> * is there any reason why you don't use calloc but use malloc + memset? > > I guess you mean in manifest.c? No, no special reason. Changed. Thanks! Thanks a lot. >> * [ccache-skip bug] > > That's funny, I just noticed and fixed that bug three days ago! I didn't > know of the patch. I haven't scanned old mailing list posts for patches; > maybe I should. For me, that bug was the only one that needed patches, I only had another one for objective-c(++) files (but that was added already) - but of course checking the archives surely doesn't hurt. >> Also I noticed that ccache now reject everything remotely looking like >> a filelist, this is a little unfortunate since OOo uses -install_name >> @_(50 underscores)identifier/libraryname to later rewrite it to the >> target location and thus those compiles won't be cached - hashing >> install_name and its value should be OK.... > > I don't quite follow you. What do you mean by "reject"? reject in this case means: doesn't even attempt to cache it. random pick from ccache-log: Compiler option @__________________________________________________OOO/libaggmxi.dylib is unsupported Failed; falling back to running the real compiler Executing /usr/bin/g++-4.0 -Wl,-multiply_defined,suppress -lobjc -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -install_name @__________________________________________________OOO/libaggmxi.dylib -dynamiclib -single_module -L../unxmacxi.pro/lib -L/Volumes/zfstest/cloph/botwork/shadow/solver/300/unxmacxi.pro/lib -L/usr/lib -o ../unxmacxi.pro/lib/libaggmxi.dylib -lpthread -lstdc++ -lm -filelist ../unxmacxi.pro/misc/libaggmxi.list Looking at it again, I realize that you can ignore most/all of that, since it is used when linking, and ccache doesn't cache linking anyway. So it boils down to bad statistics (unsupported compiler option instead of called for link), and not "doesn't cache stuff it could cache". Adding -install_name to the set of options that require an argument should do the trick, then the @____ argument will not trigger the "is too hard" case. Maybe even add -isysroot to that list, since that otherwise triggers "/Developer/SDKs/MacOSX10.4u.sdk is not a regular file, not considering as input file" in the log. But that (opposed to the linker one) would be merely cosmetics (would save a stat call) Nevertheless some background info: Locating libraries on Mac is different from how it is done on linux for example. On Mac the linker doesn't search in a set of configured directories, but all libraries have direct references to the target libraries, the only exception are the special variables @executable_path and @loader_path and @rpath (see http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html at the very bottom - "Dynamic Library Loading") OOo uses the @_____… placeholders to later rewrite those paths to the final location, depending where each lib actually ends in the final product, and third-party stuff included in OOo also make use of @executable_path (e.g icu) ciao Christian _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache