I figured out what the problem was with both of those tests - the directory I was building in had a symlink high up in the path - a 'cd $(readlink -f .)' before the build fixed it, and make/make test/make install now succeeds on our SLES12 systems.
Now I have two different test cases failing only on even-older SLES11 systems: one is in the cpp1 suite, and manifests as: Manifest has bad magic number: 1013343290 Corrupt manifest file Error reading manifest file Did not find object file hash in manifest in the ccache.log. The "bad magic number" value is always the same. This only occurs when building via a rather convoluted script that we use to crank out builds of (mostly) 3rd party packages - the failure occurs consistently in that script, but I have so far not managed to reproduce it outside. So I'm pretty certain it's got something to do with the environment rendered by the script ... no idea what, exactly, though. Any thoughts? The same script is driving the successful builds on SLES12, for whatever that's worth. The other one appears to be due to a too-old or buggy (or both) version of objdump on the oldest platform we still support - when the test suite (debug_prefix_map) runs 'objdump -g' on the file, objdump just prints the "file format" line and nothing about the debug symbols .. but objdump from a slightly less ancient os image prints the expected output. So I think I can safely ignore that one ... though that also means the same suite could be falsely passing when it checks for `pwd`. I'd submit a patch, but not sure what the best alternative would be ... fall back to readelf? -Greg Forte On Wed, Mar 21, 2018 at 7:41 AM, Forte, Greg via ccache < email@example.com> wrote: > Thanks, Joel! I haven't had much time to look at this since my previous > post, but I did discover that, for the first failing test (CCACHE_NOHASHDIR > in base suite), forcing CCACHE_BASEDIR to a common parent dir for just that > test cleared the error. Still not sure if this is actually a problem with > the test or due to some other peculiarity in my environment. > CCACHE_BASEDIR is already turned on for the other failing test, though; I > will try looking at that one with CCACHE_DEBUG_HASH when I have some time. > > -----Original Message----- > From: joel.rosd...@gmail.com [mailto:joel.rosd...@gmail.com] On Behalf Of > Joel Rosdahl > Sent: Monday, March 19, 2018 3:57 PM > To: Forte, Greg <greg.fo...@msx.bala.susq.com> > Cc: firstname.lastname@example.org > Subject: Re: [ccache] ccache test failures > > On 16 March 2018 at 12:52, Forte, Greg via ccache <email@example.com> > wrote: > > Tried this with and without CCACHE_DIR set and exported - with it, I > > see the same output you showed, including the unset, and the test > > still fails: [...] > > OK. > > What's common between the two tests that fail for you is that you don't > get a cache hit for a second compilation in another directory. One way to > understand why is to log all data that is hashed by ccache in the two cases > and see where it starts to differ. There is a crude way of doing that > already: Build ccache with -DCCACHE_DEBUG_HASH and set CCACHE_DEBUG_HASH at > runtime. Each ccache invocation will then create a ccache-debug-hash.bin > that contains the hashed data, so you could compare the files in the two > different directories. Or send them to me (private mail) and I'll have a > look. > > By the way, here's a sketch of a yet unimplemented feature what would make > this kind of debugging easier: https://github.com/ccache/ccache/issues/226 > > -- Joel > > ________________________________ > > IMPORTANT: The information contained in this email and/or its attachments > is confidential. If you are not the intended recipient, please notify the > sender immediately by reply and immediately delete this message and all its > attachments. Any review, use, reproduction, disclosure or dissemination of > this message or any attachment by an unintended recipient is strictly > prohibited. Neither this message nor any attachment is intended as or > should be construed as an offer, solicitation or recommendation to buy or > sell any security or other financial instrument. Neither the sender, his or > her employer nor any of their respective affiliates makes any warranties as > to the completeness or accuracy of any of the information contained herein > or that this message or any of its attachments is free of viruses. > _______________________________________________ > ccache mailing list > firstname.lastname@example.org > https://lists.samba.org/mailman/listinfo/ccache > _______________________________________________ ccache mailing list email@example.com https://lists.samba.org/mailman/listinfo/ccache