Looking at the recent gnulib build failures on mingw, there is a pattern of remaining issues to work on. For reference see:
http://autobuild.josefsson.org/gnulib/log-200810220353954696000.txt Two main problems appears to be: 1) pwd.h user handling functions including chown Is there any chance to implement a replacement pwd.h or grp.h header that will be useful on mingw? As far as I can tell from MSDN documentation, Windows doesn't have any numeric user identity concept. I may be wrong though, as I'm not a Windows programmer. If I'm correct, most if not all of the pwd.h and grp.h types and functions becomes impossible to adapt. See the POSIX documentation: http://www.opengroup.org/onlinepubs/009695399/basedefs/pwd.h.html http://www.opengroup.org/onlinepubs/009695399/basedefs/grp.h.html Maybe we could provide pwd.h and grp.h header files that does something like: # undef getuid # define getuid() \ (GL_LINK_WARNING ("getuid is not supported under mingw"), \ getuid ()) It may be possible to provide dummy functions on mingw for some functions, for example: int chown (const char *path, uid_t owner, gid_t group) { errno = ENOSYS; return -1; } This requires defining uid_t and gid_t to some reasonable type though. I wonder if these kind of replacements are useful, or if they just worsen the problem? It can be useful to find out the current user's username though, and this is possible under Windows (i.e., GetUserName). In GNU SASL, the only reason I use pwd.h is to get the user's username. So it may be sufficient to provide a wrapper function for this particular purpose only? On the other hand, that would result in using non-POSIX interface to do something for which there is POSIX functions for, which I dislike. 2) fork This is needed by spawni.c and savewd.c only. Possibly the spawni.c usage could be ported to Windows, supported on a best effort basis? Savewd.c uses fork to achieve something that may be possible to achieve under Windows using other mechanisms. It may be possible to port this code as well. --- Generally, I think it would be nice to identify all modules that doesn't work under mingw yet. Maybe they should even be disabled by default, when cross-compiled to mingw? I'll see if I can disable the modules that haven't been ported to mingw yet during the daily build, to be able to catch link-time problems. I suspect this will reveal more problems that should be fixed. /Simon
