<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 8/6/19 1:36 PM, Jason Wessel wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:32e8e38d-b215-b56e-d523-71811803db99@windriver.com">
      <div class="moz-cite-prefix">On 8/6/19 12:55 PM, Alexander Kanavin
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CANNYZj96=yCYWO_UG9MkUx2HvwG00v0n3dTK5aMdhqb3BHhFjw@mail.gmail.com">
        <div dir="ltr">
          <div dir="ltr"><br>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019 at
              19:31, Jason Wessel &lt;<a
                href="mailto:jason.wessel@windriver.com"
                moz-do-not-send="true">jason.wessel@windriver.com</a>&gt;
              wrote:<br>
            </div>
            <blockquote class="gmail_quote">The build of sqlite3-native
              is not fully deterministic.  There is some<br>
              corner case as shown with the recent pseudo commit where
              the sqlite3<br>
              will sometimes link against zlib.  It is possible that in
              a build with<br>
              sstate that since the zlib is not listed, that
              pseudo-native will fail<br>
              to build because it calls the pkg-config to get the link
              arguments for<br>
              sqlite3 and will ultimately try to link against zlib.<br>
            </blockquote>
            <div><br>
            </div>
            <div>It would be good to dig a little deeper and get to the
              root cause of why sqlite *sometimes* does it. The fix
              provided below seems like fixing the symptom, not the
              problem.</div>
          </div>
          <div class="gmail_quote"><br>
          </div>
          <div class="gmail_quote">Alex<br>
          </div>
        </div>
      </blockquote>
      <p><br>
      </p>
      <p>Without getting access to the build machine where it failed to
        perform more in depth forensics it is a bit hard to determine
        the exact cause.  I performed some local testing using the
        Fedora 28 and could not replicate the exact circumstance unless
        I deleted a file in the sysroot.  From what I can tell there are
        two ways of seeing the problem.  <br>
      </p>
      <p>1) Host contamination <br>
      </p>
      <p>% pkg-config sqlite3 --libs --static<br>
        -lsqlite3 -lm -ldl -lz -lpthread <br>
      </p>
      <p>This was not the way the sqlite3 was built.  However there is
        no way to know if this was the circumstance without poking
        around in the log files and re-running the context of the
        run.do_compile script in the packages temp directory.</p>
      <p>2) Dependency race<br>
      </p>
      <p>This is the one where I deleted a file to simulate the problem,
        but I couldn't reproduce it.  For this, we'd really need to look
        at the failed machine's log of the build of sqlite3, which may
        be long gone from the sstate.  But it should have the pkg-config
        files laying around.  If it shows that it did build against the
        zlib, but zlib was not listed dependency it was never going to
        build because the recipe-sysroot-native is not going to have the
        required library. <br>
      </p>
      <p>There of course might be other ways to end up with the same
        result but these are the most likely candidates, each of which
        is fixed by listing the dependency.   I too would like to know
        the actual root cause, but without access to the build it is
        hard to track it down.<br>
      </p>
    </blockquote>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>Just to follow up to be very specific about how I deleted files,
      you can see the identical failure with:</p>
    <p>sudo yum install -y zlib-devel</p>
    rm -rf tmp<br>
    <p>bitbake -c cleansstate sqlite3-native</p>
    <p>bitbake sqlite3-native</p>
    <p>sudo yum remove -y zlib-devel</p>
    <p>bitbake -c cleansstate pseudo-native</p>
    <p>bitbake pseudo-native<br>
    </p>
    <p><br>
    </p>
    <p>I seriously doubt this is exactly what is going on on the host
      builder which failed.  More analysis would be needed as I
      explained earlier to draw a final conclusion.  Either way
      sqlite3-native should be configured to build consistently, which
      would prevent this kind of contamination. <br>
    </p>
    <p>Cheers,</p>
    <p>Jason.<br>
    </p>
  </body>
</html>