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

Jan Wieck wrote:
> 
> Mark Hollomon wrote:
>
> > Jan Wieck wrote:
> > > 
> > >     A  dynamically  loadable  Tcl  module  contains  one  special
> > >     function  named  <libname>_Init()  where  first  character of
> > >     libname is capitalized.  On dynamic load,  this  function  is
> > >     called  with  the  invoking  interpreter  as  argument.  This
> > >     function then calls  Tcl_CreateCommand()  etc.  to  tell  Tcl
> >                            ^^^^^^^^^^^^^^^^^
> >
> > And here-in lies the problem. Tcl_CreateCommand is sitting, not
> > in the executable, but in the shared-lib with the function call
> > handler. dlopen(), by default will not link across shared-libs.
> >
> >           postgres
> >      /-----/  \-----\
> >      |              |
> >   plperl.so ---> Opcode.so
> >              ^^
> > This link doesn't happen.
> 
>     But  it does for PL/Tcl - at least under Linux-ELF. (C = Call
>     to, L = Location of functions code segment):
> 
>       +-------------------------+
>       |       postgres          |
>       +-------------------------+
>                    |
>                    | dynamic load
>                    |
>                    v
>       +---------------------------+          +---------------------------+
>       | pltcl.so                  |--------->| libtcl8.0.so              |
>       |                           |  auto-   |                           |
>       | C Tcl_CreateInterp()      |  dynamic | L Tcl_CreateInterp()      |
>       | C Tcl_CreateCommand()     |  load    | L Tcl_CreateCommand()     |
>       | L static pltcl_SPI_exec() |          | C pltcl_SPI_exec()        |
>       +---------------------------+          +---------------------------+
> 
>     After loading of pltcl.so,  it  calls  Tcl_CreateInterp()  to
>     build  a  Tcl interpreter, and then calls Tcl_CreateCommand()
>     to tell that interpreter the address of one  of  it's  hidden
>     (static)  functions  plus a name for it from the script side.
>     The interpreter just remembers  this  in  it's  command  hash
>     table,   and  if  that  keyword  occurs  when  it  expects  a
>     command/procedure  name,  just  calls  it  via  the  function
>     pointer.


AHHH, now I understand the difference. By default, the perl installation
does not create a shared library. It creates a static archive only.
And the three linux distros that I have experience with don't force
the creation of the shared lib. So, my situation is:
    postgres      |      |   +----------------------+            +-----------------+   |   plperl.so          |
  |  Opcode.so      |   |   +--------------+   |            |                 |   |   | libperl.a    | <-+------------|
               |   |   +--------------+   |            |                 |   +----------------------+
+-----------------+

And it is THAT link that I cannot get to happen without the RTLD_GLOBAL
flag I mentioned.

Sorry for the confusion.

Hopefully you can help find a way out of this.

I had a patch to change the way dynloader worked on linuxelf,
but over night my disk crashed. brand new UDMA/66 drive. Grrrr.


-- 

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