FS/XFS testing framework
 help / color / mirror / Atom feed
From: Paul Smith <psmith@gnu.org>
To: Zorro Lang <zlang@redhat.com>, fstests@vger.kernel.org
Cc: guaneryu@gmail.com, bug-make@gnu.org
Subject: Re: xfstests can't be installed by running make install
Date: Mon, 16 Jul 2018 07:48:26 -0400	[thread overview]
Message-ID: <ab20c4fcdf86e002d1b348f3cfa96333ed519cd8.camel@gnu.org> (raw)
In-Reply-To: <20180716073051.GH4893@hp-dl360g9-06.rhts.eng.pek2.redhat.com>

On Mon, 2018-07-16 at 15:30 +0800, Zorro Lang wrote:
> > [root@fedoravm tmp]# ls -l
> > total 4
> > -rw-r--r--. 1 root root 206 Jul 15 14:58 Makefile
> > drwxr-xr-x. 1 root root   0 Jul 15 14:59 testdir
> > [root@fedoravm tmp]# cat Makefile 
> > STRING1 = $(wildcard $(CURDIR)/[a-z]*/)
> > STRING2 = $(wildcard ./[a-z]*/)
> > default:
> >          @echo STRING1="$(STRING1)"
> >          @echo STRING2="$(STRING2)"
> > [root@fedoravm tmp]# make
> > STRING1=/root/tmp/testdir/ /root/tmp/Makefile
> > STRING2=./testdir/ ./Makefile
> > [root@fedoravm tmp]#

GNU make uses the system libc version of the glob(3) and fnmatch(3)
functions to implement its wildcard function on any system which
provides GNU libc.

So, if there's a change which introduces a problem with wildcard it is
more likely to be related to the GNU libc implementation of glob() or
fnmatch().

Unless you've somehow compiled GNU make to use its internal version of
GNU glob()/fnmatch() instead of the system version.

I filed a bug about this with GNU libc a long time ago, and it was
apparently fixed in GNU libc 2.19 in 2014.  So, I'm not sure why you've
just started seeing it now.

https://sourceware.org/bugzilla/show_bug.cgi?id=10278

  reply	other threads:[~2018-07-16 12:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11 14:33 xfstests can't be installed by running make install Zorro Lang
2018-07-11 16:39 ` Eryu Guan
2018-07-11 16:54   ` Zorro Lang
2018-07-15  5:43   ` Dave Chinner
2018-07-15  7:11     ` Eryu Guan
2018-07-16  7:30       ` Zorro Lang
2018-07-16 11:48         ` Paul Smith [this message]
2018-07-17  3:32           ` Eryu Guan
2018-07-17 20:15             ` Florian Weimer
2018-07-17 22:58               ` Dave Chinner
2018-07-18  6:26                 ` Florian Weimer
2018-07-18  3:15               ` Zorro Lang
2018-07-18  3:47                 ` Zorro Lang
2018-07-18  4:05                   ` Zorro Lang
2018-07-18  6:04                     ` Florian Weimer
2018-07-18  8:31                       ` Zorro Lang
2018-07-18  8:47                         ` Florian Weimer
2018-07-18 10:12                           ` Zorro Lang
2018-07-18 10:19                             ` Zorro Lang
2018-07-19 16:21                             ` Florian Weimer
2018-07-20  2:12                               ` Zorro Lang
2018-07-18 10:56           ` spagoveanu
2018-07-17  5:24       ` Dave Chinner
2018-07-17  5:57         ` Zorro Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab20c4fcdf86e002d1b348f3cfa96333ed519cd8.camel@gnu.org \
    --to=psmith@gnu.org \
    --cc=bug-make@gnu.org \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=zlang@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox