From: sthibault@debian.org   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)