On Jul 27 23:40, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > > 4. cd testdir-fnmatch-posix > > > > ./configure 2>&1 | tee log1 > > > > make > > > > make check > > > > I fixed the above problem and the POSIX check now works fine: > > Glad that the test suite was helpful (and that you fixed it before 3.5.0 — > so, no additional configure tests needed on the gnulib side). > > > > > grep fnmatch log1 > > > > checking for fnmatch.h... yes > > checking for fnmatch... yes > > checking for working POSIX fnmatch... yes > > > > I also extraced the fnmatch configure testcase and ran it manually. > > It returns 0 now. But: > > > > > > grep REPLACE_FNMATCH config.status > > > > S["REPLACE_FNMATCH"]="1" > > > > Looks like the reason is that we don't have a uchar.h file? Seems > > like this is of interest for AIX, but why should this be of > > interest for fnmatch on other systems? > > Ah, that's because I made the assumption that if wchar_t is only 16-bits > wide, fnmatch() can't be correct. Which is true for AIX (and on this > platform, I prefer not to test the available locales). But not true > with your implementation any more. > > What are the test suite results if you do > > - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" > in config.status, > - make clean > - ./config.status > - make
The build fails here. The reason is that the GNU extension FNM_EXTMATCH is not supported by the FreeBSD code base of fnmatch, so it's not defined in our fnmatch.h system header. Gnulib still tries to build fnmatch_loop.c which uses FNM_EXTMATCH, but apparently it now relies on using the system header? > - make check > > Then the tests will be run against Cygwin's fnmatch() function. > If all tests pass, I will add the following patch to gnulib. After the above fail, I tried from scratch with your below patch, and I still get $ grep REPLACE_FNMATCH ./config.status S["REPLACE_FNMATCH"]="1" Even though $ grep fnmatch log1 checking for fnmatch.h... yes checking for fnmatch... yes checking for working POSIX fnmatch... yes I'm quite puzzled. Corinna > > diff --git a/m4/fnmatch.m4 b/m4/fnmatch.m4 > index 2e1442eff7..e99737a476 100644 > --- a/m4/fnmatch.m4 > +++ b/m4/fnmatch.m4 > @@ -1,4 +1,4 @@ > -# Check for fnmatch - serial 18 -*- coding: utf-8 -*- > +# Check for fnmatch - serial 19 -*- coding: utf-8 -*- > > # Copyright (C) 2000-2007, 2009-2023 Free Software Foundation, Inc. > # This file is free software; the Free Software Foundation > @@ -14,7 +14,7 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] > m4_divert_text([DEFAULTS], [gl_fnmatch_required=POSIX]) > > AC_REQUIRE([gl_FNMATCH_H]) > - AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles > + AC_REQUIRE([AC_CANONICAL_HOST]) > gl_fnmatch_required_lowercase=` > echo $gl_fnmatch_required | LC_ALL=C tr '[[A-Z]]' '[[a-z]]' > ` > @@ -164,7 +164,17 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] > dnl This is due to wchar_t being only 16 bits wide. > AC_REQUIRE([gl_UCHAR_H]) > if test $SMALL_WCHAR_T = 1; then > - REPLACE_FNMATCH=1 > + case "$host_os" in > + cygwin*) > + dnl On Cygwin < 3.5.0, the above $gl_fnmatch_result came out as > 'no', > + dnl On Cygwin >= 3.5.0, fnmatch supports all Unicode characters, > + dnl despite wchar_t being only 16 bits wide (because internally it > + dnl works on wint_t values). > + ;; > + *) > + REPLACE_FNMATCH=1 > + ;; > + esac > fi > fi > if test $HAVE_FNMATCH = 0 || test $REPLACE_FNMATCH = 1; then > > > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
