[ LD ] Possible bug on LD dynamic linker option

[Beth]

Hi,

    I'm not entirely sure if this is a "bug"...or is "intended behaviour",
but for some reason I cannot fathom...but I'll report it anyway and if it's
useless then you can just ignore me...but, "just in case", I'll make the
report :)

Basically, LD seems to be using the wrong default for the "dynamic linker"
on Linux (x86)...

Trying to assemble and link a very basic X Windows example I'd written (in
NASM, though, not GAS), it appears to work (no errors are reported by the
actual assembly or linking) but the output fails to execute because LD has
linked in the wrong "dynamic linker"...

Here's the NASM source code for the program:

------------------------------------------------

; Example2.asm
;
; assemble:
; nasm -f elf -o example2.o example2.asm
;
; link:
; gcc -s -nostartfiles -o example2 example2.o -L/usr/X11R6/lib -lX11
;   or
; ld -s -o example2 example2.o -L/usr/X11R6/lib -lX11 -I/lib/ld-linux.so.2
;
; run:
; ./example2
;
                        ; handy constants
                        ;
                   NULL equ 0

                        ; make entry-point "global" so linker can see it
                        ;
                        global _start

                        ; Xlib API functions
                        ; (Xlib is a C library for programming X)
                        ;
                        extern XOpenDisplay
                        extern XDisplayName
                        extern XCloseDisplay
                        extern XDefaultRootWindow
                        extern XCreateSimpleWindow
                        extern XDestroyWindow
                        extern XSelectInput
                        extern XMapWindow
                        extern XNextEvent

                        %define KeyPressMask    1

                        %define KeyPress        2

                        ; data section
                        ;
                        section .data

       StringOpenFailed db 0Ah, "Error: Cannot open display!"
                Display dd 0
                 Window dd 0
                  event times 24 dd 0

                        ; code section
                        ;
                        section .text

                _start:
                        push byte NULL
                        call XOpenDisplay
                        add esp, 4

                        cmp eax, byte NULL
                        je near OpenFailed

                        mov [ Display ], eax

                        push byte 0
                        push byte 0
                        push byte 0
                        push 300
                        push 400
                        push byte 50
                        push byte 50

                        push dword [ Display ]
                        call XDefaultRootWindow
                        add esp, 4
                        push eax

                        push dword [ Display ]
                        call XCreateSimpleWindow
                        add esp, 36

                        cmp eax, byte NULL
                        je CreateFailed

                        mov [ Window ], eax

                        push KeyPressMask
                        push dword [ Window ]
                        push dword [ Display ]
                        call XSelectInput
                        add esp, 12

                        push dword [ Window ]
                        push dword [ Display ]
                        call XMapWindow
                        add esp, 8

           MessageLoop:
                        push event
                        push dword [ Display ]
                        call XNextEvent
                        add esp, 8

                        cmp dword [ event ], KeyPress
                        jne MessageLoop

                        push dword [ Window ]
                        push dword [ Display ]
                        call XDestroyWindow
                        add esp, 8

          CreateFailed:
                        push dword [ Display ]
                        call XCloseDisplay
                        add esp, 4

                        jmp Terminate

            OpenFailed:
                        mov eax, 4
                        mov ebx, 1
                        mov ecx, StringOpenFailed
                        mov edx, 27
                        int 80h

             Terminate:
                        mov eax, 1      ; function (sys_exit)
                        xor ebx, ebx    ; exit code
                        int 80h         ; make Linux system call

------------------------------------------------

And, when I try the following:

$ nasm -f elf -o example2.o example2.asm
$ ld -s -o example2 example2.o -L/usr/X11R6/lib -lX11
$ ./example2

bash: ./example2: /usr/lib/libc.so.1: bad ELF interpreter: No such file or
directory

$ /lib/ld-linux.so.2 --list ./example2
    libX11.so.6    => /usr/X11R6/lib/libX11.so.6 (0x4001e000)
    libdl.so.2     => /lib/libdl.so.2 (0x400fd000)
    libc.so.6      => /lib/libc.so.7 (0x40100000)
    /usr/lib/libc.so.1    => /lib/ld-linux.so.2 (0x800000000)

BUT, if I use GCC instead:
$ nasm -f elf -o example2.o example2.asm
$ gcc -s -nostartfiles -o example2 example2.o -L/usr/X11R6/lib -lX11
$ ./example2

..it runs okay...and here's what I get for the links being made:

$ /lib/ld-linux.so.2 --list ./example2
    libX11.so.6    => /usr/X11R6/lib/libX11.so.6 (0x4001e000)
    libdl.so.2     => /lib/libdl.so.2 (0x400fd000)
    libc.so.6      => /lib/libc.so.7 (0x40100000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x800000000)

..the difference is that final line...now, if I use LD's "-I" option to
explicitly specify this file to LD:

$ nasm -f elf -o example2.o example2.asm
$ ld -s -o example2 example2.o -L/usr/X11R6/lib -lX11 -I/lib/ld-linux.so.2
$ ./example2

..then this runs okay too...and has the same "--list" output as the GCC
version...

What "might" be a bug here - I don't know - is that LD isn't linking the
correct "dynamic linker" automatically...this might be "intended behaviour"
but it seems odd to me that the "default" would be to link in the wrong
"dynamic linker" (indeed, it seems be linking in an ancient "libc" as the
"dynamic linker"...could that be "intended"? It doesn't execute properly,
for sure :)...

Also, I saw a USENET posting that independently was reporting the same
problem, trying to use LD on an assembly language example that uses X...

Plus, my example code here was to be a "demonstration" for how to program X
using the NASM assembler and I posted up the code...and others are
reporting that they are experiencing the exact same problems...which seems
to rule out that it's anything to do with my particular "configuration"...

Though, for the record: GNU ld version 2.13.90.0.18 20030206

And this is LD as it was installed by Red Hat 9 from their distribution...I
have not re-compiled it or altered anything since (but, as I say, others
with different distributions are also seeing the same thing on their
machines too, which seems to rule out this having anything to do with
that)...

Oh, this is for the x86, of course, as if the assembler code hadn't already
made that clear ;)

I have the "work-around" for it, as noted, in explicitly specifying the
"dynamic linker" using the "-I" option (or using GCC to access LD, which
seems to automatically specify the "dynamic linker" or something...it
doesn't get the problem, anyway, whatever GCC is doing ;)...

But is this "intended behaviour" for it to use the wrong "dynamic linker"?
As I would have thought not because that means LD produces invalid output
which won't run...

I thought I'd better "report" it, though..."just in case" this isn't right
and it simply hasn't been noticed (as people probably use GCC in some
context for programming X - and not solely stand-alone assembly language
code - and the problem isn't there using GCC but only when using LD
alone...so, it _might_ have been "missed" or something :)...LD appears to
be using the wrong "default" for the "dynamic linker" (or does it not have
a "default"? I don't know, as I'm not sure exactly why LD is doing
this...obviously...or I'd know if it is a "bug" or not...but you're the
people to ask about this, right? :)

Beth :)