I have a directory with three sub folders wherein I built a cross gcc. So there are the directories binutils, gcc and glibc that are only the build directories, the corresponding sources are in different directories. Everything went fine, I compiled and installed everything to some custom path.

When I now try to enter the subdirectory glibc (of my build tree) I cannot list the contents, I get some error message that itself is not readable:

$ ls
ls: �����: ��dJ: Error 1673445588re

If I do it again, another error number appears:

$ ls
ls: �vP��: ��u: Error 3137748

Or a concrete file:

 $ ls config.status
 ls: : ���s: Error 123785428

If I list the contents from one hierarchy above, it works:

 $ ls glibc
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map

If I become root and enter the directory, I can list it as well:

 # ls 
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map

The folder itself:

 $ ls -lh glibc -d
 drwxr-xr-x 63 david david 4.0K 17. Aug 16:30 glibc

Correct owner, correct permissions.

I already ran

  # e2fsck -pfc /dev/sdb4

No change.

There is no error in any log file, dmesg does not show any error, the file system check reported no error, what on earth can that be?


The fact that I was building a cross gcc leads to the assumption that my environment is affected by those libraries or binaries. During cross compilation or during the build of the cross gcc I indeed adjust the path for the shell that I build the environment with and have it point to the installation path of the cross gcc. But gcc does not provide /bin/ls or the like, also my LD_LIBRARY_PATH and the like are unset. The ls command comes from my system:

$ where ls
ls: aliased to ls --color=always
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffea1362000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc18b429000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc18b7c2000)

Everything else (seems) to work fine, I don't have any other problem with my system or this SSD (Samsung SSD 840 EVO 500GB, EXT0DB6Q). After several reboots, the problem remains.

What I haven't realized so far - if I stand within this directory, EVERY ls command fails, I can't even list my home directory anymore:

$ ls ~
ls: ���e�: �i"�5: Error 18446744071861719252

Different output every time:

$ ls ~
ls: Pg��: ��{
: Error 2070020308

~/cross-build/inc100/glibc # this is the path to this directory
$ echo $PATH


$ ls glibc
.... libc.so libc.so.6

If I move the file libc.so to something like libc.so.backup from one directory above and then enter the directory, it works!

It seems that the linker finds this libc.so in this directory and simply uses it? But why does echo work and ls not? find also behaves wrong. And how can I avoid this behaviour?

Update echo works because it is a shell builtin, ls, find etc. are binaries linked to libc.so, that's the reason for the different behaviour.

I still don't know why this happens and how I can avoid it, I really don't want this "window-ish" behaviour.

  • Total guess, but looks like file system corruption to me. – Tigger Aug 18 '17 at 8:32
  • @Tigger Thanks for the tip, but isn't e2fsck supposed to find the corruption? Or is it possible that the file system is corrupt but e2fsck does not realize it? – David Aug 18 '17 at 8:49
  • What are you doing with this glibc? Didn't you change your system glibc (or the glibc with what your ls is running) to it? – peterh Aug 18 '17 at 9:02
  • @peterh Thanks, good catch but no, I was building a cross compiler and this glibc is installed in a separate folder in my home directory. The ls I use is not linked to nor does it catch the cross-compiled libc. My LD_LIBRARY_PATH is unset and my PATH (in the above calls) does not contain any of the bin-folders of the cross-compilation root. – David Aug 18 '17 at 9:20

Maybe your ls command is not /bin/ls?. Try to check if ls is really /bin/ls in every directory with command:

which ls

I assumed there is an executable file named ls in those directory, and your $PATH environment variable executed that command instead of /bin/ls.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.