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
