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
next prev parent 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