<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson <<a href="mailto:spam@scientician.net">spam@scientician.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Once you have that bit set up, you can copy *most* of the libraries<br>
.so's you're using to that folder on the install target and they'll be<br>
loaded from there. (Copying libc.so is ill advised, but most of the<br>
others will work just fine. I believe ld-linux-... is also never ever<br>
loaded from there since that *is* the dynamic loader.)</blockquote><div><br><div dir="ltr"><div>Not 100% certain, but I think the issue with libc may be that it may be somewhat tied to the ld-linux.</div><div><br></div><div>You can actually copy everything, including ld-linux, though. You then invoke the program via ld-linux (it's actually an executable -- see the ld.so page)</div><div><br></div><div>./ld-linux-x86_64.so.2 --library-path <path to copied libraries> <executable> <args> ...</div></div><div><br></div><div>If you wrap your binaries with a shell script it is actually pretty clean (make sure to exec so you don't windup with the shell sitting between parent and childs that can cause some subtle issues)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"></div></div>The only real breakage I've seen from this is when you try and run on too old of a kernel for your libc or the remote system has an unusual nsswitch plugin you didn't provide.</div></div></div>