From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) When dynamically linking an executable, ld by default specifies /lib/libc.so.1 as the linker, so you have to specify -dynamic-linker /lib/ld-linux.so.2 to get ld to build dynamic executables. gcc does this, so it's only a problem when running ld manually, but according to the ld docs, ld should know where it is anyway. Reproducible: Always Steps to Reproduce: 1. Create an assembly file that requires symbols from libc 2. assemble it - as test.s -o test.o 3. link it - ld test.o -o test -lc 4. run it - ./test - you will get the message "./test - no such file or directory" 5. run objdump -s test, you will see a reference to /lib/libc.so.1, which doesn't exist 6. link it again with - ld test.o -o test -lc -dynamic-linker /lib/ld-linux.so.2 7. run it - ./test - runs perfectly Actual Results: You get "./test - no such file or directory" Expected Results: The program should have run normally
Created attachment 16766 [details] Source file to assemble to find the bug
No, ld behaviour is correct, you have to specify -dynamic-linker (well, even better the gcc driver). ld documentation is not linux specific and on many targets the default dynamic linker is appropriate. The thing is that you're linking for elf_i386 emulation (no linux mentioned anywhere in that name fyi), and IA32 psABI specifies the ABI dynamic linker as /usr/lib/libc.so.1.