[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
close: lseek+unistd+sys_socket on mingw results in failure
From: |
Simon Josefsson |
Subject: |
close: lseek+unistd+sys_socket on mingw results in failure |
Date: |
Thu, 30 Oct 2008 23:07:20 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) |
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
- close: lseek+unistd+sys_socket on mingw results in failure,
Simon Josefsson <=