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 -- 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
