Paul, > > I suppose another possible hack is to replace the ifdef with > > something like m4_ifdef([gl_[]THREADLIB], ...); I haven't > > investigated that. > > I tried that, and it seems to work. It strikes me that > other gnulib macros play the m4_ifdef trick too, e.g., > gl_FUNC_WRITE does m4_ifdef([gl_NONBLOCKING_IO], ...). > Perhaps they also need to obfuscate their symbol too? > If not, what's a good rule of thumb for deciding whether > symbols need obfuscating to escape aclocal's attention?
I think we need to hide from 'aclocal' only those identifiers that occur in .m4 files installed publicly, such as through gettext. > Anyway, getting back to to the main topic, here is a combined > patch that doesn't involve altering gnulib-tool. Still, it does not address the points 1) and 2) of <http://lists.gnu.org/archive/html/bug-gnulib/2011-07/msg00256.html>. Therefore I still object to it. > since it changes pthread_sigmask to work > even when threadlib is absent, it removes the dependency of > pthread_sigmask on threadlib. But that is wrong. If someone wants to use pselect() in a library, that library may be linked into multithreaded programs. With your patch, the package that provides the library and blindly requests 'pselect' will get a pselect() emulation that is not multithread-safe. Whereas in the current situation, the pselect() emulation will be multithread-safe by default. And the package maintainer can make the *conscious* decision to use gl_THREADLIB_DEFAULT_NO and in consequence build a not multithread-safe library. Bruno -- In memoriam Jane Haining <http://en.wikipedia.org/wiki/Jane_Haining> <http://www.shoah.dk/Courage/Haining.htm>
