Micah Cowan <[EMAIL PROTECTED]> writes:
>> It sounds like a libc problem rather than a gcc problem. Try
>> #undefing SYSTEM_FNMATCH in sysdep.h and see if it works then.
>
> It's hard for me to imagine an fnmatch that ignores FNM_PATHNAME: I
> mean, don't most shells rely on this to handle file globbing and
> whatnot?
The conventional wisdom among free software of the 90s was that
fnmatch() was too buggy to be useful. For that reason all free shells
rolled their own fnmatch, as did other programs that needed it,
including Wget. Maybe the conventional wisdom was right for the
reporter's system.
Another possibility is that something else is installing fnmatch.h in
a directory on the compiler's search path and breaking the system
fnmatch. IIRC Apache was a known culprit that installed fnmatch.h in
/usr/local/include. That was another reason why Wget used to
completely ignore system-provided fnmatch.
In any case, it should be easy enough to isolate the problem:
#include <stdio.h>
#include <fnmatch.h>
int main()
{
printf("%d\n", fnmatch("foo*", "foo/bar", FNM_PATHNAME));
return 0;
}
It should print a non-zero value.
