Subject: gnu make wildcard function problem

From: Nicholas Clark <[email-masked]>
Date: Sun, 11 Apr 1999 21:26:12 +0100 (BST)

Sorry if this sounds incoherent. Not sure why this crops up with 2.2.5
but not 2.2.3. Sufficient to say that it does.

The linux kernel makefile uses the wildcard function in gnu make a
lot, including globbing things like *.c to pass to make depend.
On 2.2.5 my .depend files have size 0.

I've traced this to a failure of the wildcard function in gnu make to
expand wildcards. gnu make (3.77) is using glibc's glob() function,
but with alternate opendir/readdir/closedir functions.

And there lies the problem.
sizeof(struct dirent) == 268 normally, but 272 when _FILE_OFFSET_BITS
is #defined as 64. Which gnu make does. So its "readdir" function
fakes a 272 sized struct which is passed back to glibc's glob. Which
(as far as I can tell) was expecting a 268 byte structure, and
consequently fails to find the name in the correct place. So no names
are read from the directory, and glob() always fails to expand any
patterns passed.

gnu make sources contain the glibc glob code, in case you're compiling
on a platform with no glob() in libc. If I use this code as stands
(static link) then make still fails. If I use the same code but
compile with -D_FILE_OFFSET_BITS=64 then make works again.

Is this really as broken as it seems to be (gnu make 3.77, glibc 2.1).
And why haven't I noticed under 2.2.3? I'm back in 2.2.3 and my test
Makefile of

all:
	echo $(wildcard *.c)

still mucks up.

I'm I barking up the wrong tree or just barking?

Nick
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicholas Clark <[email-masked]>
Date: Sun, 11 Apr 1999 21:48:10 +0100 (BST)

> And why haven't I noticed under 2.2.3? I'm back in 2.2.3 and my test

Answer:

Compiled 2.2.3 on 28th March.
rebuilt make on 29th March

previous make was a.out, and could $(wildcard) just fine

(compiled before glibc2.1, as IIRC glibc demands gnu make 3.77 for compilation)

> I'm I barking up the wrong tree or just barking?

Question still stands. :-)
As does the question "should sizeof (struct dirent) change in this way?"

Nick