From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id 72FB93858D33; Fri, 28 Jul 2023 11:12:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72FB93858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1690542732;
	bh=nxHzJEuwRnsWbu4Nol1d3qbAbpQtBcMp4aRaR3yOCXg=;
	h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
	b=CZEKigWPZNYwztgS5kXttQD8QAAzMbe5rrr8omNCoVUc6C7Zzuk+dcyDLYmeFCVwN
	 urt75jQkkoHGgOn6YEVIO4M1m1kaTEbxBjjyAaCIfMono5X75mIjc348kZEXXcIG6I
	 en0tvWux4BDzt+1Rbnx/XJh12AEvhB1b2sWsZuGs=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id EE039A80C7B; Fri, 28 Jul 2023 13:12:09 +0200 (CEST)
Date: Fri, 28 Jul 2023 13:12:09 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Cc: Bruno Haible <bruno@clisp.org>
Subject: Re: fnmatch improvements
Message-ID: <ZMOiiRYqhCdSc+mm@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Corinna Vinschen via Cygwin <cygwin@cygwin.com>,
	Bruno Haible <bruno@clisp.org>
References: <3884636.3uDm00564X@nimes>
 <ZMK2UVB71pEeoFDK@calimero.vinschen.de>
 <ZMLADRFGUuvEnCT+@calimero.vinschen.de>
 <12689051.0j3nEXixpK@nimes>
 <ZMOCGyArlcmVAxI5@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZMOCGyArlcmVAxI5@calimero.vinschen.de>
List-Id: <cygwin.cygwin.com>

On Jul 28 10:53, Corinna Vinschen via Cygwin wrote:
> On Jul 27 23:40, Bruno Haible via Cygwin wrote:
> > Corinna Vinschen wrote:
> > >     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?
> [...]
> 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.

I'm puzzled because I'm an idiot.  I forgot autoreconf.  After that and
another configure run, REPLACE_FNMATCH is correctly set to 0 *and* the
build runs fine.

I'll do the rest of the test later today.

Sorry,
Corinna