<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 February 2017 at 14:00, 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"><div class="gmail-HOEnZb"><div class="gmail-h5">On Wed, 2017-02-01 at 13:44 +0200, Jussi Kukkonen wrote:<br>
> On 1 February 2017 at 13:23, Richard Purdie <richard.purdie@linuxfoun<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 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 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 look.<br>
> > ><br>
> > > As far as I could see outputpath (based on state[2]) was 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 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 just<br>
> > call relpath on the original path and turn it into a relative 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>
</div></div>Good point, I knew I was missing something. How about passing in<br>
walkroot/state[1] into the function, then you can subtract that from<br>
the actual file, then run relpath between the (srcpath - walkroot) and<br>
the link?<br></blockquote><div><br></div><div>Figuring out a sysroot-based path for srcpath is indeed possible (and nicer) using state[1] but then I have:</div><div> path /usr/lib/ssl/certs</div><div> link /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-r0/recipe-sysroot-native/etc/ssl/certs</div><div><br></div><div>Without knowledge of TMPDIR or WORKDIR, I don't see how I can turn link into anything like</div><div> ../../../etc/ssl/certs</div><div><br></div><div>Maybe I'm missing something?</div><div><br></div><div>Jussi</div></div></div></div>