This command:
rm -rf m;gnulib-tool --create-testdir --dir m --with-tests lseek unistd
sys_socket; cd m;./configure --host=i586-mingw32msvc
--build=i686-pc-linux-gnu;make check;cd ..
Fails like this:
test-lseek.o: In function `main':
/home/jas/src/gnulib/m/gltests/test-lseek.c:89: undefined reference to
`_close_used_without_requesting_gnulib_module_close'
/home/jas/src/gnulib/m/gltests/test-lseek.c:90: undefined reference to
`_close_used_without_requesting_gnulib_module_close'
The reason is that the unistd.h replacement looks like:
#if 0
# if 1
/* Need a gnulib internal function. */
# define HAVE__GL_CLOSE_FD_MAYBE_SOCKET 1
# endif
# if 0
/* Automatically included by modules that need a replacement for close. */
# undef close
# define close rpl_close
extern int close (int);
# endif
#elif 1
# undef close
# define close close_used_without_requesting_gnulib_module_close
#elif defined GNULIB_POSIXCHECK
# undef close
# define close(f) \
(GL_LINK_WARNING ("close does not portably work on sockets - " \
"use gnulib module close for portability"), \
close (f))
#endif
Is it appropriate to use a hard error in this situation? If it was a
warning, it would be something that could be ignored.
Should the lseek-tests module depend on close? That feels wrong to me,
it doesn't use close in a non-portable way, and certainly not in the way
that the close module is intended to work around.
/Simon
