Hey, > > Your patch will not work, as $LIB cannot tell what binary arch will be > > called and do not know anything from multiarch. At least I read the > > documentation like this. > > The patch gets the core concept right and that's turning the package > continaing libtorsocks.so M-A:same.
I still don't understand, how this can work. BUt maybe torsocks shell was
changed in meanwhile... I now more or less understand the fakeroot approch and
will go that path.
> > That one is quite easy:
> > * the lib is already installed at the correct place *check*
> > * all other files are arch independent *check*
> > * the only file we need to care about is /usr/bin/torsocks.
> > I use here the easy solution to move the binary to /usr/bin/$
> > {MULTI_ARCH_TRIPPLET}-torsocks
>
> That solution is fairly annoying to users as running torsocks no longer
> works. You now have to know what architecture your wrapped executable
> has. That may even be impossible if you wrap an amd64 shell that wants
> to execute an i386 executable.
ACK this is annoying - it was simply the only known solution I knew.
> > Or are you aware of any other solution to make use the correct torsocks
> > script /LD_PRELOAD?
>
> I'm not sure I fully understand the fakeroot implementation, but the
> general approach also used by eatmydata seems to be installing the
> library directly into /usr/lib/<triplet> without a subdirectory and then
> listing the library name in LD_PRELOAD without the
> architecture-dependent leading directory components. fakeroot does not
> follow this path and instead adds a ld.so.conf.d snippet, but I don't
> think that's any better.
Well as libtorsocks is a internal library, that does not even ship a abi numer
( only .so) I think this should been kept in a own directory.
The way I see now to get torsocks script ready is:
* change LD_PRELOAD="libtorsocks.so" within torsocks script
* ship a ld.so.conf.d snippet (named torsocks-<tripplet>.conf) within
libtorsocks:any
* mark torsocks as Arch:all and M-A:foreign
* get rid of /usr/bin/<tripplet>-torsocks, as they are not needed anymore
=> I tested this on my own laptop and it works ;)
fakeroot does not make it easy to spot onto relevant parts, as it is obvious
not 100% multi-arch ready. fakeroot ships a amd64 path within the shell script.
In the concequence $ABSLIB at least not work for multi-arch. but this ABSPATH
is not used by default..., because USEABSLIBPATH == 0.
/usr/bin/fakeroot:amd64
#l37
FAKEROOT_LIB=libfakeroot-sysv.so
PATHS=/usr/lib/x86_64-linux-gnu/libfakeroot:${FAKEROOT_PREFIX}/lib64/libfakeroot:${FAKEROOT_PREFIX}/lib32/libfakeroot
#l1113
for dir in `echo $PATHS | sed 's/:/ /g'`
do
if test -r "$dir/$FAKEROOT_LIB"
then
libfound=yes
ABSLIB="$dir/$FAKEROOT_LIB"
fi
done
regards,
hefee
--
On Mittwoch, 5. März 2025 09:08:48 Mitteleuropäische Normalzeit Helmut Grohne
wrote:
> On Wed, Mar 05, 2025 at 12:01:16AM +0100, Hefee wrote:
> > Your patch will not work, as $LIB cannot tell what binary arch will be
> > called and do not know anything from multiarch. At least I read the
> > documentation like this.
>
> The patch gets the core concept right and that's turning the package
> continaing libtorsocks.so M-A:same.
>
> > But let's focus on the first step is to get torsocks multi-arch ready, so
> > it can be installed as multi-arch: same.
>
> Yes, this aspect is part of any solution.
>
> > That one is quite easy:
> > * the lib is already installed at the correct place *check*
> > * all other files are arch independent *check*
> > * the only file we need to care about is /usr/bin/torsocks.
> > I use here the easy solution to move the binary to /usr/bin/$
> > {MULTI_ARCH_TRIPPLET}-torsocks
>
> That solution is fairly annoying to users as running torsocks no longer
> works. You now have to know what architecture your wrapped executable
> has. That may even be impossible if you wrap an amd64 shell that wants
> to execute an i386 executable.
>
> The approach of triplet-prefixing is great for cross building as most of
> the tooling knows the triplet and it merely is a matter of propagating.
> It is not great at all for this use case.
>
> > @helmut:
> Consider mailing d-cross@l.d.o instead of me. Yeah, the question is not
> the core topic of the list, but it is close enough.
>
> > But as a enduser I just want to use /usr/bin/torsocks, so I need a wrapper
> > script. I would use the "easy" solution ans just use the main architecture
> > (dpkg --print-architecture), but how to get the multi-arch-name for the
> > main architecture?
>
> The problem kinda is that there is no "right architecture". In my
> example of calling an amd64 shell that invokes a 32bit binary, neither
> is right.
>
> > Or are you aware of any other solution to make use the correct torsocks
> > script /LD_PRELOAD?
>
> I'm not sure I fully understand the fakeroot implementation, but the
> general approach also used by eatmydata seems to be installing the
> library directly into /usr/lib/<triplet> without a subdirectory and then
> listing the library name in LD_PRELOAD without the
> architecture-dependent leading directory components. fakeroot does not
> follow this path and instead adds a ld.so.conf.d snippet, but I don't
> think that's any better.
>
> Helmut
signature.asc
Description: This is a digitally signed message part.
