<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO - Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100073#c11">Comment # 11</a>
on <a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO - Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100073">bug 100073</a>
from <span class="vcard"><a class="email" href="mailto:t_arceri@yahoo.com.au" title="Timothy Arceri <t_arceri@yahoo.com.au>"> <span class="fn">Timothy Arceri</span></a>
</span></b>
<pre>(In reply to oiaohm from <a href="show_bug.cgi?id=100073#c9">comment #9</a>)
<span class="quote">> Jan Vesely
> <b>If the pointer size is the same and the timestamp is the same, the cache
> will be reused, not deleted, and the problem does not exist.</b>
>
> I have a little problem. I have x32 and i386. So pointer size is the same
> timestamp and contents of cache should be different. This will happen if I
> am running a reproducible build with frozen time. This can also happen if
> you make to 64 library builds with frozen time because the two builds will
> have the same timestamps even if they are completely different versions of
> mesa incompatible disc cache requirements.
>
> <a href="https://reproducible-builds.org/docs/timestamps/">https://reproducible-builds.org/docs/timestamps/</a>
>
> The reason I provided this link is time is no longer trust-able as a unique
> value. Do note the usage of libfaketime its really simple to forget you
> still have that loaded after doing a reproducible build so the clock is not
> in fact ticking forwards for anything you are doing you wake up when you
> finally do something that is dependant on the clock in fact ticking. So
> you need to look at other sources to get unique value.</span >
x32 should end up in the ilp-32 directory. That's what the __ILP32__ is meant
to do. Even if it didn't and the cache wasn't deleted because all your arch
builds had the same timestamp it still wouldn't matter because the timestamp is
used to identify the Mesa version not the arch, the arch doesn't matter in
terms of the cache it will work just fine. The only reason for the different
dirs is because we have no way of knowing if the different timestamps are the
same Mesa version</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>