Subject: Re: shared object problem
To: Arne H Juul <arnej@math.ntnu.no>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 07/25/1998 13:15:45
[replys set to port-mips, I doubt it's pmax-specific or affects alpha]

In message <19980725021718.24646.qmail@romberg.math.ntnu.no>,
    Arne Juul  <arnej@math.ntnu.no> writes:

>I've been looking at perl and trying to figure out why dynamic
>module loading doesn't work, and I've found that it's because
>the dynamic modules can't get the symbols back in the main program
>right.  Appended is a test case, compile with:

># cc main.c -o main
># cc -c -fPIC fred.c
># ld -x -shared fred.o -o fred.so
># ./main

>I think this should work, at least it does on NetBSD/i386 and
>IRIX/mips, so I guess it's ld.elf_so that doesn't work right.
>
>Does other NetBSD/pmax people get the same results with ld.elf_so?

It coredumps for me too.

My guess is, this is another mips GOT-entry-resolution bug and it
works just fine on an Alpha. Doesn't perl on alphas work with .so
dynaloading?

The symbols in the dynamically-linked fred.so aren't being resolved
against the symbols in main().  I wonder what would happen if fred
calls rename() instead of a function in main(): if main is linked
against -lposix before -lc, does elf.ld_so DTRT there?

Michael Hitch has been in the bowels of this more recently than I,
fixing the rename() bug above. I can guess where they are (i did then)
but I'm not intimately familiar with the code.

If we fix this, perl should work with dynaloading shared libs
(instead of static) on mips, too, right?