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
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils