On Fri, Apr 11, 2008 at 08:23:19AM +0200, Simon Josefsson wrote: > > Thanks. But does LinuxThreads need -D_REENTRANT today? The links to > the gnulib list I gave suggested that it isn't necessary, but without > knowing exactly what to test it is difficult to know for sure.
I think that testing that errno is thread local instead of global is a good test to see if it's needed. I know that "extern int errno;" used to work on systems using LinuxThreads, but that it fails to link on systems using NPTL. But even the errno.h from i386 sarge seems to use (*__errno_location ()). So it looks to me that _REENTRANT is only used to make some functions like getlogin_r available. > I don't know much about thread stuff, but my hope is that we could > derive some concrete explanation of what breaks if you don't add > -D_REENTRANT when building debian packages. That would make it possible > to come back to this text later and evaluate whether the reasons for > having the text are still valid. I think that on a Debian system using glibc using _REENTRANT isn't needed if: - You don't need specialy reentrant functions from libc; - Other libraries you're using have something in their include files that change behaviour depending on _REENTRANT; - The package you're building itself doesn't change change behaviour depending on _REENTRANT. I think that libraries in Debian should never change behaviour based on _REENTRANT. If a library can be build to either support threads or not, it should be compiled to support threads. It might also want to provide one that does and one that doesn't so that you can link to either one, but I would like to discourage that, and the default library should be the one that supports threads. And if it does provide 2 libraries, the header files for both should be the same and not depend on _REENTRANT. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
