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.
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
5. run objdump -s test, you will see a reference to /lib/libc.so.1, which
6. link it again with - ld test.o -o test -lc -dynamic-linker
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.