Cannot list directory from within, only from outside

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?

Update

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
/bin/ls
$ 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
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-
bin/5.4.0:/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-
bin/6.4.0:/home/david/usr/bin

Hm:

~/cross-build/inc100/
$ 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.