Re: dynloader and PLs [was: plperl intial pass] - Mailing list pgsql-hackers

From Mark Hollomon
Subject Re: dynloader and PLs [was: plperl intial pass]
Date
Msg-id 379DF521.73DECD66@americasm01.nt.com
Whole thread Raw
In response to Re: dynloader and PLs [was: plperl intial pass]  (wieck@debis.com (Jan Wieck))
List pgsql-hackers
Jan Wieck wrote:
> 
> Mark Hollomon wrote:
> 
> > I had a patch to change the way dynloader worked on linuxelf,
> 
>     I don't think you should change the entire dynamic loader  of
>     PostgreSQL  for  it.  This  could  be  a can of worms and you
>     should be happy that these problems showed up already on your
>     development  platform.  I don't expect that you're willing to
>     fix the dynamic loading under  AIX,  HP-UX  and  Solaris  too
>     (maybe   you   can't   because   the   lack   of  appropriate
>     environment).
> 

The problem is that perl and postgres disagree as how to do
the dynamic loading. postgres (on linux) _Always_ use aout
style dynamic loading. Perl checks to see if the system is ELF
and use dlopen if it is. On my ELF system then, postgres is
loading plperl.so with dl_open (?). Then perl is loading
Opcode.so using dlopen. The problem seems to be that the symbols
from libperl.a (in plperl.so) are not available for resolving
missing symbols in Opcode.so. The error message basically mentions
every perl symbol as 'unresolved'.

I noticed in another thread that D'Arcy is strugling with a similar
problem in NetBSD.

On my system, once I got postgres and perl to agree on how to do
dynamic loading, I got XS stuff working. The code is (mostly)
already in plperl.c, but ifdef'ed out.


-- 

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008


pgsql-hackers by date:

Previous
From: Jonathan Stone
Date:
Subject: Re: [HACKERS] More on shared objects problem
Next
From: Todd Vierling
Date:
Subject: Re: More on shared objects problem