bash: ./helloworld_s: no such file or directory. The file is clearly there - linux

Question

I'm not unfamiliar with bash, but this is the first time I have ever seen this happen.
[OP#localhost linking]$ ls
helloworld-lib.o helloworld-lib.s helloworld_s
[OP#localhost linking]$ ./helloworld_s
bash: ./helloworld_s: No such file or directory
This error occurred while I was testing the linker, ld. The contents of helloworld-lib.s are:
[OP#localhost linking]$ cat helloworld-lib.s
.section .data
helloworld:
.ascii "Hello, world!\n\0"
.section .text
.globl _start
_start:
mov $helloworld, %rdi
call printf
mov $0, %rdi
call exit
This file helloworld_s was produced as follows.
[OP#localhost linking]$ as helloworld-lib.s -o helloworld-lib.o
[OP#localhost linking]$ ld -lc helloworld-lib.o -o helloworld_s
IDK if any of this information is relevant. As an FYI, if I attempt to run the other files, I just get a permission denied (as expected). Any ideas?
EDIT: as suggested, here is the output of ls -l:
[OP#localhost linking]$ ls -l
total 88
-rw-rw-r--. 1 OP OP 968 Mar 23 18:40 helloworld-lib.o
-rw-rw-r--. 1 OP OP 159 Mar 23 18:40 helloworld-lib.s
-rwxrwxr-x. 1 OP OP 14384 Mar 23 18:41 helloworld_s
here is the output of id:
[OP#localhost linking]$ id
uid=1000(OP) gid=1000(OP) groups=1000(OP),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
EDIT: for answer, see comments. See here

Answer 1

As explained in redhat bug #868662 , the recommanded way to link is to let gcc call ld like below;
> gcc -nostartfiles helloworld-lib.o -o helloworld_s -lc
Which results in correct linking;
> ldd helloworld_s
linux-vdso.so.1 => (0x00007ffd283bf000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd011b62000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd011f2f000)
And execution goes fine;
> ./helloworld_s
Hello, world!
Why does ld link to /lib/ld64.so.1 which does not exist ?
Because this is the default setup for a generic system, not only Linux.

Answer 2

Existent executables may be confusingly reported as missing under circumstances where the actual issue is that they cannot be executed.
Actual causes vary, but include things such as
the file is defective, perhaps as a result of invalid linking as mentioned in another answer
the file is for a different architecture or ABI unsupported by the platform
the file lacks an execute permission bit for the user attempting to do so
the file is on a volume mounted with flags which prohibit execution
In many of these cases, it's clear that a more specific and relevant error message would have been preferable, however, sometimes what is actually implemented (or triggered by less than obvious paths of failure) can indeed be confusing in the sense of labelling something that is "unusable" as being "missing" How precise errors are can vary somewhat between environments.