bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]