On Thu, Oct 6, 2016 at 12:06 PM, Paul Smith <psm...@gnu.org> wrote:
> > 4.2.1 definitely broken, at least on my system.
>
> It works on my system. I've tried it multiple times. I'm using Ubuntu
> GNOME 16.04.1, with GNU libc 2.23, on an ext4 filesystem.
>
Broken here on on Debian using the Linux kernel with glibc 2.23 on ext4:
$ ldd ~/make-4.2.1
linux-vdso.so.1 (0x00007ffdc316c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbd5495f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd545be000)
/lib64/ld-linux-x86-64.so.2 (0x000056101b9e3000)
$ dpkg -S /lib/x86_64-linux-gnu/libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
$ dpkg -l libc6:amd64
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-================-=============-=============-======================================
ii libc6:amd64 2.23-5 amd64 GNU C Library: Shared
libraries
Make was compiled from the source tarball with Debian's gcc 6.1.1.
I can't explain why your system is behaving differently. Perhaps your
> version of libc has an issue with the glob() or fnmatch() functions
> (it's happened before). Or maybe there's a bug in GNU make which is
> system-dependent in some way.
>
It seems unlikely that this is an artifact of my specific system
configuration, since I see the exact same behavior on MacOS. Starting from
a clean directory (only Makefile exists there):
$ ~/make-4.2.1
touch target1
touch target2
touch target3
touch target4
touch target5
touch target6
touch target7
touch target8
touch target9
touch target10
glob:
$ ~/make-4.2.1
glob: target4 target2 target1 target5 target6 target7 target8 target9
target10 target3
$ uname -a
Darwin bos-mpi8u 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34
PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
$ ~/make-4.2.1 --version
GNU Make 4.2.1
Built for x86_64-apple-darwin15.6.0
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ otool -L ~/make-4.2.1
/Users/krose/make-4.2.1:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
Not Linux, not glibc, and not ext4.
Incidentally, make in this instance was also compiled from the same source
tarball, but with Apple LLVM version 8.0.0 (clang-800.0.38).
> Clearly, but it appears to be a defect that can only reproduced on your
> system (so far), so you'll have to do a bit more digging. Rewriting
> the directory caching facility isn't the answer.
>
I trust you saw Martin's email?
If you send me a filtered ltrace:
ltrace -s 255 make 2>&1 >/dev/null | egrep -v -e
'^(mem|str|free|malloc|__str|calloc|qsort)' -e resumed
I might be able to track down where the behavior differs on (AFAICT) very
similar system configurations (Debian and Ubuntu with the same minor
version of glibc). My gut tells me there's an inconsistency in the test
setup, not in GNU make's behavior given the same starting conditions, which
is exhibiting the same behavior on very different configurations (Debian
vs. MacOS).
Kyle
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
