On Wed, Apr 06, 2016 at 08:43:23PM +0200, Christian Seiler wrote: > Peter Pentchev wrote: > > So, the thing is, now it's in an arch:all package; it examines the program > > that the user asked it to run, then chooses the /usr/lib/*/dante-client/libdsocksd.so > > file for the correct architecture (thus the multiarch-find-lib tool), puts it > > into LD_PRELOAD, then runs the program that the user asked it to run. > > The thing is, now you can have several dante-client-lib (arch-specific) packages > > containing the various /usr/lib/*/dante-client/libdsocksd.so helpers, and > > one socksify to bind them, thus allowing you to run e.g. both amd64 and i386 > > binaries through SOCKS proxies. This was impossible until now, and I have > > a couple of bug reports in the BTS to prove it :) > > There's a much easier way to do this, btw.: if a library is directly in > /usr/lib/$triplet, then setting LD_PRELOAD=library.so.X will work > without you having to find the proper multi-arch related library. See > how e.g. my own gtk3-nocsd package does it: library goes to > /usr/lib/$triplet, and wrapper just sets LD_PRELOAD=libgtk3-nocsd.so.0. > ld.so does the rest automatically (assuming the M-A: same package is > installed for the architecture required). Hmm, yes, I even do this in the multiarch-find-lib tool - if a library is present in the ldconfig output, I just output its name letting the loader do exactly what you say. *head scratch* Now why did I not even think of using the same trick to preload dante's client library? Hah, this might make things easier indeed, thanks! > Also, if a program called in such a way forks and executes another > program, if that other program is on a different architecture, ld.so > will automatically do the right thing. Example: you call a script, > which uses an amd64 interpreter, but the script itself doesn't do any > network calls but rather calls an i386 binary to actually connect to > the network. And if I read your multiarch-find-lib right, it doesn't > appear to even handle shebang-interpreters at the moment? Actually it handles shebang-interpreters - I tested it (and dante) with a couple of simple Perl one-liners and a couple of more complicated programs both in C and Perl. Look for "a hashbang thing" near line 219 of multiarch-find-lib. > (Btw. I find it way easier to just set a SONAME for the preloaded > library and add a symbols file, plus also follow Debian package naming > conventions based on the soname, than to either ignore the lintian > warnings about missing SONAME or override them, which will become > necessary if the preloadable library resides directly in the canonical > /usr/lib/$triplet path directly.) Yes, that's partly the reason why I didn't go that way - this would be another deviation from the Dante upstream source. But it seems that it would make the whole thing a bit easier, so I may indeed do that, thanks for pointing me in the right direction! G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature