Hi,

Currently torsocks FTBFS on GNU/Hurd due to lacking OS support. It did
build previously, latest Hurd version is 1.3-3. The attached patch
re-enables the build of torsocks for Hurd. All tests in the testsuite
pass. (Perhaps maybe some comments in the patch are redundant, please
let me know.)

Thanks!

Svante Signell, le Wed 29 Oct 2014 15:04:08 +0100, a écrit :

Err, but then how is it supposed to work at all?

Samuel

These are only case statements in syscall.c to the handle functions.

Svante Signell, le Wed 29 Oct 2014 15:21:32 +0100, a écrit :

Yes, but what is is supposed to do with "arbitrary numbering"?  What is
the torsocks code actually making of it?

Samuel

Hi David,

could you please have a look at this Debian bug report:

https://bugs.debian.org/767235

Thanks in advance!

[Dropping the "patch" tag, as it seems unclear that the patch actually
does the right thing.]

Cheers,
--
intrigeri

[intrigeri 2014]

As far as I can tell, the tsocks_syscall() function is not used on Hurd, thus
failing to hijack connect(), close(), socket() and several other system calls.

we are now in 2026 so this is open since more than 10 years now :( I would
like to fix this. Unfortunately I do not understand why this patch fix the usage
on hurd.

Can you explain why this fixes the issue?

Actually you need to convince upstream to add your patch. I want to have a
minimal diff with upstream, that's why I would only include it in Debian if
upstream accepts the patch. I can also forward a MR, but without being able to
explain it does not make sense to forward a MR.

https://gitlab.torproject.org/tpo/core/torsocks/-/merge_requests

Regards,

hefee

Hello,

Hefee, le jeu. 19 févr. 2026 13:05:26 +0100, a ecrit:

Looking at the change, it seems to be circumventing the fact that
syscall() is not really defined on GNU/Hurd.  Instead of defining
arbitrary values for TSOCKS_NR_*, we could as well put the syscall
redirection code inside #ifndef __GNU__ since there is nothing to
redirect, applications running on GNU/Hurd won't ever be using
syscall().

Samuel

Hey,

Thanks for your fast explanation.

Okay digging deeper into the code I see, that also the linux part on compat.h
has these numbering [1]. So it is not that uncommon.

[1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/
common/compat.h?ref_type=heads#L74

The change on configure.ac I understand, that this reflects in the correct libc
version. But buildd is actually fine with the configure step, so is that still
needed?

torsocks.h okay it changed their hunks, but seems fine.

I think the change on syscall.c is not needed anymore, as they changed to
negative logic [2].
https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/lib/
syscall.c#L87

I now have a feeling, that I understand and could ask upstream, if you can
update the patch for the new version. At least hunks have changed and it would
be nice if we propose a working patch for upstream.

I'm a little bit lost in the preprocessor macros. Is __GNU__ only only true
for Hurd?

Regards,

hefee

Hefee, le jeu. 19 févr. 2026 15:49:53 +0100, a ecrit:

To get the proper libc_name to be able to dlopen() it, yes.
https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/lib/syscall.c#L87

Indeed.

Yes, it's really only for GNU/Hurd and not the other GNU variants.

Samuel

Hey,

that's for the fast responses.

Will you update the patch, so that will apply to the current torsocks version
2.5.0? Me don't have any insights in hurd, so it would proberly takes ages to
update the patch.

Will you create a upstream MR with that patch or should I forward that?

regards,

hefee

PS: btw. but a different issue - also HURD/amd64 is failing but already in the
configure step:
https://buildd.debian.org/status/fetch.php?pkg=torsocks&arch=hurd-amd64&ver=2.5.0-5&stamp=1771514351&raw=0

Hello,

Hefee, le mar. 24 févr. 2026 13:57:26 +0100, a ecrit:

Here is an updated patch, which notably simply drops the syscall() part
since that's not actually used on GNU/Hurd.

Please forward it.

Samuel

Hey,

forwarded the patch to upstream.

regards

hefee