fileutils ls struct dirent --> glibc struct dirent64

ls -l reports:
/hdc2/tools/2002/shell/bin/ls: : No such file or directory
/hdc2/tools/2002/shell/bin/ls: : No such file or directory
/hdc2/tools/2002/shell/bin/ls: : No such file or directory
ie each name has a NUL byte at the front

gdb shows field sizes:	ls	glibc
	struct		dirent	dirent64
	d_ino		8	8
	d_off		4	8
	d_reclen	2	2
	d_type		1	1
	d_name		...	...

Breakpoint:
	ls.c 		line 1763	print_dir
	readdir.c	line 42		__READDIR

d_name is offset by 4 and usually picks up a NUL byte at the start.
I can guess that this is an installation issue, picking up the
wrong header, or the wrong #define, but I cant find where.
The background system is mandrake 7.2, but it SHOULD be picking
up new things all round, with a local prefix:

	glibc-2.2.5  (not libc-2.1.3)
	fileutils-4.1
	gcc-3.3 (CVS)
	linux-2.4.19
	cpu-i586 AMD

fileutils was compiled last, glibc was built with gcc-3.2 which
built 3.3, and /usr/include/linux does-> /usr/src/linux/include/linux.
ldd and type shows that the new prefixes are being used, though
they do have their own different prefixes:

	/tools/2002/glibc
	/tools/2002/shell

I have the output from configure and build, if that helps.
The scripts I use (21K) to build with are: (a moving target)

	http://homepage.ntlworld.com/information-cascade/baks/
	2002_go.tar.gz

gdb (insight-cvs) seems to be capable of resolving the different dirent
topologies, do you want me to run some utility to see what was?

I realise that my setup is confusing, but how did fileutils get
the wrong header, or modifiers?


   regards
--
   Graham
   [email protected]

PS:
	I saw recently that RedHat are staggering their releases,
	so that (Oracle-etc) dont fall between two levels.
	My experience is that libc-2.2.5 wont load things from 2.1.3