[Pkg-privacy-maintainers] Bug#767235: torsocks: FTBFS on hurd-i386

[Samuel Thibault]

Hefee, le jeu. 19 févr. 2026 15:49:53 +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().
> 
> 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?

To get the proper libc_name to be able to dlopen() it, yes.

> 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

Indeed.

> 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?

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

Samuel