This is on an ext4 file system.
It's not locale dependent: the same result occurs with 'LC_ALL=C make check'.
$ nm make | grep wildcard
000000000040f820 t func_wildcard
$ nm make | grep glob
0000000000408620 T ar_glob
0000000000408280 t ar_glob_match
000000000040b220 T dir_setup_glob
0000000000408210 t __do_global_dtors_aux
0000000000632e08 t __do_global_dtors_aux_fini_array_entry
0000000000634560 b global_dl.6802
00000000006341d0 d global_setlist
0000000000637080 b global_variable_set
0000000000424760 T init_hash_global_variable_set
On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote:
> Hi Paul,
> > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:
> > This is because the glob() function in the older GNU libc has a bug
> > related to handling symlinks correctly.
> Gnulib provides a workaround against this bug in its 'glob' module
> . But GNU make ships a copy of glob.c from 1999 :-(
Yes, I know.
Unfortunately, attempting to pull gnulib's glob/fnmatch implementation
also pulls in a bajillion other gnulib modules, and causes lots of
problems for GNU make on non-POSIX systems like Windows (where we
support native builds without any Cygwin/MinGW support) and VMS
(obviously we have no sed/etc. tools there).
I have on my list to tackle this issue but it's daunting.
You may have noticed my emails to the gnulib list asking about doing
things in ways that reduce the number of native tools needed for the
configure step ... this is one of the main reasons why.
> On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote:
> > > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:
On filesystems which don't populate dirent::d_type (or on old glibc) test 7
On Sun, Apr 05, 2020 at 11:07:31AM -0400, Paul Smith wrote:
> I have on my list to tackle this issue but it's daunting.
That would be good if the fix cited above was applied before you sync with