<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 10:09 AM, Simon Eisenmann <span dir="ltr"><<a href="mailto:simon@struktur.de" target="_blank">simon@struktur.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Snapcraft wrappers only set the LD_LIBRARY_PATH to the arch which was<br>
used where snapcraft is run.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is not sufficient to create multi arch snaps with snapcraft. The<br>
wrappers need to detect the arch where the wrapper is run and then set<br>
the path accordingly.<br>
<br>
Moreover to have multi arch support there also needs to be some way to<br>
have the same binary for multiple architectures.</blockquote><div><br></div><div>Oh yes, there is still work to do in snapcraft for dealing with multiple target architectures or simple cross-builds. I'd add that we should also support biarch for folks running 32-bits x86 binaries on x86-64 – I ran in a case where the same snap would have to run 64-bits and 32-bits utilities. For now, this can be worked around by running snapcraft on different architectures natively or in a qemu-system-$arch chroot, but that results in multiple snaps.</div><div><br></div><div>It's all just snapcraft work that needs to get done  :-)</div><div><br></div><div>I agree LD_LIBRARY_PATH should be set dynamically for multi-architecture snaps.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would want to avoid having to rename binaries (eg by adding the arch<br>
suffix) and consider to create some arch based folder tree instead.<br></blockquote><div><br></div><div>Seems right; perhaps this only has to be done for multi-arch snaps though</div><div><br></div><div>Cheers,</div><div>-- </div><div>Loïc</div><div><br></div></div></div></div>