The immediate problem is that ld
uses /lib/ld64.so.1
as interpreter by default and you may be missing that (it can be a symlink to /lib64/ld-linux-x86-64.so.2
or whatever is appropriate):
$ readelf -l a.out | grep interpreter
[Requesting program interpreter: /lib/ld64.so.1]
$ ls -l /lib/ld64.so.1
ls: cannot access /lib/ld64.so.1: No such file or directory
You can work around this by setting the interpreter explicitly by passing -dynamic-linker /lib64/ld-linux-x86-64.so.2
option to your ld
invocation:
$ ld -s -dynamic-linker /lib64/ld-linux-x86-64.so.2 test.o -lc
$ readelf -l a.out | grep interpreter
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ ./a.out
$
The simple rule of thumb however is to use gcc
for linking if you need libc, it will do everything right for you. Also make sure you use main
as entry point so that normal libc startup code has a chance of initializing. Similarly, just return from your main
at the end and do not use exit
syscall directly (you may use the exit
function from libc if you really want). In general, using syscalls is not recommended.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…