gl_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK is wrong in some cases
Hello!
gnulib is used by libvirt project (http://libvirt.org), and during
cross-compiling libvirt i stumbled upon a problem in gnulib's autoconf
module.
The problem happens under the following conditions:
--build=i686-mingw32 --host=arm-linux-gnueabihf
Yes, i am cross-compiling Linux version of libvirt under Windows. It works
fine except this small test. The problem is in the first line:
--- cut ---
if test "$as_ln_s" = "ln -s" && ln -s conftest.file conftest.sym; then
AC_RUN_IFELSE(
[AC_LANG_PROGRAM(
[AC_INCLUDES_DEFAULT],
[[struct stat sbuf;
/* Linux will dereference the symlink and fail, as required by
POSIX. That is better in the sense that it means we will
not
have to compile and use the lstat wrapper. */
return lstat ("conftest.sym/", &sbuf) == 0;
]])],
[gl_cv_func_lstat_dereferences_slashed_symlink=yes],
[gl_cv_func_lstat_dereferences_slashed_symlink=no],
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu*) gl_cv_func_lstat_dereferences_slashed_symlink="guessing
yes" ;;
# If we don't know, assume the worst.
*) gl_cv_func_lstat_dereferences_slashed_symlink="guessing
no" ;;
esac
])
else
# If the 'ln -s' command failed, then we probably don't even
# have an lstat function.
gl_cv_func_lstat_dereferences_slashed_symlink="guessing no"
fi
--- cut ---
AC_RUN_IFELSE() is supposed to perfectly handle cross-compilation case and
it knows that *-gnu* systems normally answer "yes" to this test. However,
"$as_ln_s" = "ln -s" test spoils everything on MinGW because 'ln' is
substituted by 'cp' there (because there is no support for symlinks in MinGW
for historical reasons).
I would suggest to fix this by explicit check for "cross-compiling" = "no"
before attempting the whole thing:
--- cut ---
if test "$cross_compiling" = no; then
--- the whole original AC_RUN_IFELSE() thing goes here, except
cross-compile fragment ---
else
# cross-compiling
case "$host_os" in
# Guess yes on glibc systems.
*-gnu*) gl_cv_func_lstat_dereferences_slashed_symlink="guessing
yes" ;;
# If we don't know, assume the worst.
*) gl_cv_func_lstat_dereferences_slashed_symlink="guessing no"
;;
esac
fi
--- cut ---
Anyway, this test makes no sense when build != host.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
RE: gl_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK is wrong in some cases
Hello! > Thanks for reporting the problem. Does the attached fix things for you? Yes, this variant also works fine. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
pthread_sigmask() detected incorrectly on MinGW by configure
Hello! I have found one more problem with GNULib on Windows. This time it concerns pthread_sigmask(). configure script detects it as present, and this is technically correct, but: --- cut --- /* Windows has rudimentary signals support. */ #define pthread_sigmask(H, S1, S2) 0 --- cut --- (see http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-librar ies/winpthreads/include/pthread_signal.h) So, this is actually incorrect. And this causes failure building gnulib's pthread_sigmask.c, because it tries to refer original pthread_sigmask() after #undef'ing it. Of course this causes "undefined symbol" while linking. I would suggest that configure script just knows that on *-mingw* systems pthread_sigmask is not present. An alternate way to fix this is to add to the .c file: --- cut --- #ifdef _WIN32 #undef HAVE_PTHREAD_SIGMASK #endif --- cut --- Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
RE: pthread_sigmask() detected incorrectly on MinGW by configure
Hello! > I would suggest that configure script just knows that on *-mingw* > systems pthread_sigmask is not present. Small oops: if you check $host_os, then it should be just "mingw*", because the triplet is "i686-pc-mingw32", there's no 4th component like ...-gnu-... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
RE: pthread_sigmask() detected incorrectly on MinGW by configure
Hello! > Any implementation that defines 'pthread_sigmask' only as a macro, and > not as a function, doesn't conform to POSIX and we should be able to > reject it at compile-time. Perhaps you can suggest a patch along those > lines? Well... We could do a preprocessor-based test in configure. Something like: --- cut --- if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then dnl pthread_sigmask is available with -pthread or -lpthread. AC_PREPROC_IFELSE([AC_LANG_SOURCE([[ #include #ifdef pthread_sigmask #error is a macro #endif ]])], [ LIB_PTHREAD_SIGMASK="$LIBMULTITHREAD" ], [ HAVE_PTHREAD_SIGMASK=0 REPLACE_PTHREAD_SIGMASK=1 ]) --- cut --- Would that do ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
[PATCH] Check whether pthread_sigmask is a simple macro
GNULib's pthread_sigmask() is configured and builds incorrectly on MinGW64. Configure script detects it as present, and this is technically correct, but: --- cut --- /* Windows has rudimentary signals support. */ #define pthread_sigmask(H, S1, S2) 0 --- cut --- (see http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthread s/include/pthread_signal.h) And this causes failure building gnulib's pthread_sigmask.c, because it tries to refer to original pthread_sigmask() after #undef'ing it. This patch recognizes that pthread_sigmask is a simple macro and there's no real function behind it, and in this case it produces the following settings: HAVE_PTHREAD_SIGMASK=0 LIB_PTHREAD_SIGMASK='' REPLACE_PTHREAD_SIGMASK=1 so that pthread_sigmask() is entirely emulated by GNULib. Related topic: http://lists.gnu.org/archive/html/bug-gnulib/2015-04/msg00065.html Signed-off-by: Pavel Fedin m4/pthread_sigmask.m4 | 24 1 file changed, 24 insertions(+) diff --git a/m4/pthread_sigmask.m4 b/m4/pthread_sigmask.m4 index 5c17dfc..a974848 100644 --- a/m4/pthread_sigmask.m4 +++ b/m4/pthread_sigmask.m4 @@ -40,6 +40,30 @@ AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK], LIBS="$gl_save_LIBS" ]) if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then +AC_CACHE_CHECK([whether pthread_sigmask is only a macro], + [gl_cv_func_pthread_sigmask_is_macro], + [gl_save_LIBS="$LIBS" + LIBS="$LIBS $LIBMULTITHREAD" + AC_LINK_IFELSE( + [AC_LANG_PROGRAM( +[[#include + #include + #undef pthread_sigmask +]], +[[return pthread_sigmask (0, (sigset_t *) 0, (sigset_t *) 0);]]) + ], + [gl_cv_func_pthread_sigmask_is_macro=no], + [gl_cv_func_pthread_sigmask_is_macro=yes]) + LIBS="$gl_save_LIBS" + ]) +if test $gl_cv_func_pthread_sigmask_is_macro = yes; then + dnl On MinGW pthread_sigmask is just a macro which always return 0. + dnl It does not exist as a real function, which is required by POSIX. + REPLACE_PTHREAD_SIGMASK=1 + gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD=no +fi + fi + if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then dnl pthread_sigmask is available with -pthread or -lpthread. LIB_PTHREAD_SIGMASK="$LIBMULTITHREAD" else -- Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
[PATCH RESEND] Check whether pthread_sigmask is a simple macro
GNULib's pthread_sigmask() is configured and builds incorrectly on MinGW64. Configure script detects it as present, and this is technically correct, but: --- cut --- /* Windows has rudimentary signals support. */ #define pthread_sigmask(H, S1, S2) 0 --- cut --- (see http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthread s/include/pthread_signal.h) And this causes failure building gnulib's pthread_sigmask.c, because it tries to refer to original pthread_sigmask() after #undef'ing it. This patch recognizes that pthread_sigmask is a simple macro and there's no real function behind it, and in this case it produces the following settings: HAVE_PTHREAD_SIGMASK=0 LIB_PTHREAD_SIGMASK='' REPLACE_PTHREAD_SIGMASK=1 so that pthread_sigmask() is entirely emulated by GNULib. Related topic: http://lists.gnu.org/archive/html/bug-gnulib/2015-04/msg00065.html Signed-off-by: Pavel Fedin m4/pthread_sigmask.m4 | 24 1 file changed, 24 insertions(+) diff --git a/m4/pthread_sigmask.m4 b/m4/pthread_sigmask.m4 index 5c17dfc..a974848 100644 --- a/m4/pthread_sigmask.m4 +++ b/m4/pthread_sigmask.m4 @@ -40,6 +40,30 @@ AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK], LIBS="$gl_save_LIBS" ]) if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then +AC_CACHE_CHECK([whether pthread_sigmask is only a macro], + [gl_cv_func_pthread_sigmask_is_macro], + [gl_save_LIBS="$LIBS" + LIBS="$LIBS $LIBMULTITHREAD" + AC_LINK_IFELSE( + [AC_LANG_PROGRAM( +[[#include + #include + #undef pthread_sigmask +]], +[[return pthread_sigmask (0, (sigset_t *) 0, (sigset_t *) 0);]]) + ], + [gl_cv_func_pthread_sigmask_is_macro=no], + [gl_cv_func_pthread_sigmask_is_macro=yes]) + LIBS="$gl_save_LIBS" + ]) +if test $gl_cv_func_pthread_sigmask_is_macro = yes; then + dnl On MinGW pthread_sigmask is just a macro which always return 0. + dnl It does not exist as a real function, which is required by POSIX. + REPLACE_PTHREAD_SIGMASK=1 + gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD=no +fi + fi + if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then dnl pthread_sigmask is available with -pthread or -lpthread. LIB_PTHREAD_SIGMASK="$LIBMULTITHREAD" else -- Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
[PATCH] Fix building tests under Windows
1. grantpt.c seems to be never used on Windows, however it's still present in
tests/ subdirectory of the final project. Therefore it breaks 'make check'.
2. Windows has no PTYs, therefore gnulib's openpty() will just return -ENOSYS.
The main problem is test-openpty.c which expects termios to be there. Just make
it building and silently passing the test.
Signed-off-by: Pavel Fedin
---
lib/grantpt.c| 2 +-
tests/test-openpty.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/grantpt.c b/lib/grantpt.c
index a740091..3658fcd 100644
--- a/lib/grantpt.c
+++ b/lib/grantpt.c
@@ -46,7 +46,7 @@
int
grantpt (int fd)
{
-#if defined __OpenBSD__
+#if (defined __OpenBSD__) || (defined _WIN32)
/* On OpenBSD, master and slave of a pseudo-terminal are allocated together,
through an ioctl on /dev/ptm. There is no need for grantpt(). */
return 0;
diff --git a/tests/test-openpty.c b/tests/test-openpty.c
index 9fc4ed2..ee36fe6 100644
--- a/tests/test-openpty.c
+++ b/tests/test-openpty.c
@@ -34,6 +34,7 @@ int
main ()
{
{
+#ifndef _WIN32
int master;
int slave;
@@ -103,6 +104,7 @@ main ()
/* Close the master side before the slave side gets closed.
This is necessary on Mac OS X 10.4.11. */
close (master);
+#endif
}
return 0;
--
1.9.5.msysgit.0
