<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 February 2017 at 14:53, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2017-02-01 at 14:38 +0200, Jussi Kukkonen wrote:<br>
> On 1 February 2017 at 14:00, Richard Purdie <richard.purdie@linuxfoun<br>
<div><div class="gmail-h5">> <a href="http://dation.org" rel="noreferrer" target="_blank">dation.org</a>> wrote:<br>
> > On Wed, 2017-02-01 at 13:44 +0200, Jussi Kukkonen wrote:<br>
> > > On 1 February 2017 at 13:23, Richard Purdie <richard.purdie@linux<br>
> > foun<br>
> > > <a href="http://dation.org" rel="noreferrer" target="_blank">dation.org</a>> wrote:<br>
> > > > On Wed, 2017-02-01 at 12:03 +0200, Jussi Kukkonen wrote:<br>
> > > > > Recipe-specific sysroots broke make_relative_symlink(), which<br>
> > > > > turns absolute symlinks in sysroots into relative ones. Use<br>
> > the<br>
> > > > > difference between the (in-sysroot) paths to construct the<br>
> > > > relative<br>
> > > > > symlink.<br>
> > > > ><br>
> > > > > This fixes links in openssl-native, fontconfig-native and<br>
> > bzip2-<br>
> > > > > native.<br>
> > > > ><br>
> > > > > Signed-off-by: Jussi Kukkonen <<a href="mailto:jussi.kukkonen@intel.com">jussi.kukkonen@intel.com</a>><br>
> > > > > ---<br>
> > > > ><br>
> > > > > sstate is not an area I'm familiar with, please take a good<br>
> > look.<br>
> > > > ><br>
> > > > > As far as I could see outputpath (based on state[2]) was<br>
> > never<br>
> > > > really<br>
> > > > > needed so I did not use it in the new version.<br>
> > > ><br>
> > > > I don't think we can hardcode workdir into here as for tasks<br>
> > like<br>
> > > > do_deploy, this makes no sense. I think we removed most of the<br>
> > > > absolute<br>
> > > > links from the deploy tasks so we currently don't need this, at<br>
> > > > least<br>
> > > > in the common case but the sstate code is meant to be generic.<br>
> > > ><br>
> > > > I am wondering if we need to pass in anything at all, can't we<br>
> > just<br>
> > > > call relpath on the original path and turn it into a relative<br>
> > one<br>
> > > > directly without referencing it back to TMPDIR/WORKDIR?<br>
> > > ><br>
> > > The actual file path during do_populate_sysroot is something like<br>
> > > /mnt/extra-ssd/tmp/work/x86_<wbr>64-linux/openssl-native/1.0.<wbr>2j-<br>
> > > r0/sysroot-destdir/mnt/extra-<wbr>ssd/tmp/work/x86_64-linux/<wbr>openssl-<br>
> > > native/1.0.2j-r0/recipe-<wbr>sysroot-native/usr/lib/ssl/<wbr>certs<br>
> > ><br>
> > > and the link before make_relative_symlink() points to <br>
> > > /mnt/extra-ssd/tmp/work/x86_<wbr>64-linux/openssl-native/1.0.<wbr>2j-<br>
> > > r0/recipe-sysroot-native/etc/<wbr>ssl/certs<br>
> > ><br>
> > > Assuming those are correct, I don't see how to do this without<br>
> > > referencing WORKDIR or TMPDIR?<br>
> ><br>
> > Good point, I knew I was missing something. How about passing in<br>
> > walkroot/state[1] into the function, then you can subtract that<br>
> > from<br>
> > the actual file, then run relpath between the (srcpath - walkroot)<br>
> > and<br>
> > the link?<br>
><br>
> Figuring out a sysroot-based path for srcpath is indeed possible (and<br>
> nicer) using state[1] but then I have:<br>
> path /usr/lib/ssl/certs<br>
<br>
</div></div>Are you sure path isn't /mnt/extra-ssd/tmp/work/x86_<wbr>64-linux/openssl-<br>
native/1.0.2j-r0/recipe-<wbr>sysroot-native/usr/lib/ssl/<wbr>certs ?<br></blockquote><div><br></div><div>state[1] really is the whole thing until and including "recipe-sysroot-native":</div><div> /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-r0/sysroot-destdir/mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-r0/recipe-sysroot-native<br></div><div>removing that prefix from path leaves me with</div><div> /usr/lib/ssl/certs</div><div><br></div><div><br></div></div></div></div>